61–70 of 112 posts
Congrats though well done on release.
Earlier quoted context omitted.
No. Structural types are called structural types. The best known typeclass implementation is that of Haskell where they're built into the language, but Scala has them as a pattern implemented with implicits; I can try to explain the concept here if you like but honestly there are probably better explanations out there. Typeclasses are more powerful than structural types in that the implementation doesn't have to be t…
> The best known typeclass implementation is that of Haskell Oh, I don't know about that one. In Scala type-classes are interfaces and you can put that OOP to good use. For example in the Cats library, you get an Applicative type-class inheriting from Apply, a FlatMap inheriting from Apply and a Monad inheriting from FlatMap and Applicative. By comparison in Haskell a Monad is not automatically an Applicative and you…
actually I'm still unsure about kotlin. some things are really great some things are not. I mean i will still use kotlin, especially for libraries since it is great for that. however somehow I still missed something on top of Executors and CompletionStage. And I'm totally unhappy about "So, why doesn’t Kotlin have its own package manager, or its own build system? Because there’s already Maven and Gradle, and re-using…
Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plug…
Earlier quoted context omitted.
Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.
Actually criticism is mostly personal however there are a few: - I dislike the DSL // not a really useful criticism I know. - Some things needs Groovy which isn't a mainstream language - Had Bad support for Scala, which I use heavily mostly resolved since 2.2 and thanks to linkedin newer version even have twirl + playframework support. - sometimes the syntax file of the DSL couldn't be highlighted in eclipse / intell…
Originally on Gradle.org's website, they wrote they'd encourage anyone who wanted to enable Gradle to allow another scripting language for writing build files, and that they'd help them with bundling it. But since Gradle 2, it looks like too much of Gradle's own source and plugin code is written in Groovy for that to still be feasible. Gradleware also employed one of the former developers who used to work on Groovy when they were retrenched by VMWare a year ago, and I suspect he'd actually sabotage any outside attempt to make Gradle polyglot, like, say, Vert.x is. So it looks like you're stuck with Groovy if you want to use Gradle. With the good comes the bad, as they say!
Been using it for a while, glad 1.0 is out! This is an amazing replacement for Java on Android and hope it gets more public recognition now that it's officially out.
Must admit I wish Jetbrains just contributed more of their time on existing open source languages instead of creating a complete new one. There is enough languages out there and this is one more thing i wont have time to look at :) Congrats though well done on release.
It's almost like Kotlin was designed for Android to bring new life to its ancient Java version.
Kotlin sort of feels like Groovy "done properly" (with no disrespect to the authors of Groovy). Groovy kind of evolved in an opportunistic, unplanned manner and ended up with millions of features, cool whiz bang aspects that look awesome that don't always turn out well when you use them on a large scale. Kotlin seems to capture the same ideas (highly pragmatic, maintain perfect bidirectional compatibility with Java),…
Earlier quoted context omitted.
So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want. And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.
You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.
Your criticism applies equally to non-build code. Don't approve PRs for bad/inscrutable code.
In gradle you can build plugins just like maven. But a simple 'if then' doesn't require all the heavy lifting of a plugin.
Kotlin is a beautifully designed language: small, modern + statically typed that's naturally terse and elegant - ideal for both OOP and LINQ-like/functional programming: https://github.com/mythz/kotlin-linq-examples Thanks to JetBrain's tooling prowess it also has great integration with Android Studio - Light years better for functional programming than Java 1.7: https://github.com/mythz/java-linq-examples Which can…
LINQ is not (just) an interface over some collections. It is a comprehension syntax (that kotlin doesn't have) that works on any types that have Select/SelectMany/Where.
This gives you a lot more power than what Kotlin gives you, as you can 'extend' other things that don't inherit from an IEnumerable; for instance Task or a custom data type that has its own inheritance hierarchy.
The 'comprehension' part means you can deeply nest things (similar to scala's for compehension) without building up a stack of {}. This is quite common when doing asynchronous programming, and Kotlin doesn't really help you out at all here.
Earlier quoted context omitted.
how do you do conditionals or loops in maven?
> how do you do conditionals or loops in maven? What you're asking for is Turing-complete XML. History has shown that this is usually a mistake.