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

Kotlin Is Better

steve-yegge.blogspot.com

Post reply on HN
Print view View original

171–180 of 229 posts

Re: Kotlin Is Better

#171

Post by dahauns »

mpweiher wrote: post #79
hota_mazi wrote: post #67

Earlier quoted context omitted.

> for non-static languages like Python, they're just not very good Yup. Because they can't. Without type annotations, IDE's are pretty much incapable of offering automated refactorings without human supervision (and yes, that includes Smalltalk IDE's). They can give you some primitive auto completion and navigation, but that's pretty much it.

> Yup. Because they can't. Actually they can. > incapable of offering automated refactorings without human supervision > (and yes, that includes Smalltalk IDE's) Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser. The lack of static type information was considered a…

Please. With all due respect towards Smalltalk and all the pioneering work it did, stop it with the Refactoring Browser as a shining example for automated refactoring.

No, it really can't, not with the correctness guarantees of a statically typed language.

If you are required to run tests to do refactoring, you're simply not on the same level.

The last paragraphs in this link for an example (Ironic title, I know. :) ):

http://wiki.c2.com/?DynamicTypesEaseRefactoring

Re: Kotlin Is Better

#172

Post by fauigerzigerk »

cel1ne wrote: post #95
Larrikin wrote: post #60

Earlier quoted context omitted.

Extension functions as mentioned are extremely useful. There's just some functionality you need on different types of Android classes (especially views, activites, and fragments) very often but it really isn't worth it to subclass it since not all views or activites need all of the functionality. The improvement to findViewById was met with tepid applause today because its hardly used anymore due to there being a lot…

If you got time, play around with extensions with multiple receivers, you can do pretty neat stuff with them. See my comment here: https://news.ycombinator.com/item?id=14365317

What's the advantage of extension functions compared to plain functions?

  fun String.shout() = this + "!!!"

  fun shout(s: String) = s + "!!!"
Looks pretty much the same to me. Extension functions use static dispatch so what's the point of using member syntax?

Also, extension functions can be overwritten by a member function with the same signature. That seems quite fragile to me considering the class and the extension function very likely have different authors.

That said, I don't know Kotlin very well. So perhaps you can set me straigt on any misconceptions I may have.

Re: Kotlin Is Better

#175

Post by ensiferum »

How exactly does kotlin fix the bad Android apis? You'd imagine that you still have to deal with the apis.

"Whereas Kotlin is made by world-class IDE vendors, so right from the start it has the best tooling support ever."

And then...

IntelliJ doesn't like it when you type fast. Its completions can't keep up and you wind up with half-identifiers everywhere.

So sounds like the tool support really isn't great.

Re: Kotlin Is Better

#176

Post by Delmania »

skrowl wrote: post #143
bpicolo wrote: post #20

I've started to come around on a similar thought recently, after a few years avoiding static typing in python. I've been toying with C# specifically. C# with visual studio is, I think, the most productive environment I've come across in programming. It's ergonomically sound, straightforward, and the IDE protects me from all sorts of relevant errors. Steve mentioned Intellij is a bit slower than he'd hope typing somet…

If you know C# you don't really need Kotlin. You can write windows, windows universal, web, linux console, Android and iOS apps, all native, and all in C#.

Some of us still develop desktop applications on Linux in Java SE. Kotlin is a godsend.

Re: Kotlin Is Better

#177

Post by Larrikin »

fauigerzigerk wrote: post #172
cel1ne wrote: post #95

Earlier quoted context omitted.

If you got time, play around with extensions with multiple receivers, you can do pretty neat stuff with them. See my comment here: https://news.ycombinator.com/item?id=14365317

What's the advantage of extension functions compared to plain functions? fun String.shout() = this + "!!!" fun shout(s: String) = s + "!!!" Looks pretty much the same to me. Extension functions use static dispatch so what's the point of using member syntax? Also, extension functions can be overwritten by a member function with the same signature. That seems quite fragile to me considering the class and the extension…

I use extension functions on classes I don't own to add functionality I think the class should have had or would be extremely useful for my project if a certain type of class had the functionality. Your example would require a static utility class in Java or an object in Kotlin to use every where, the extension functions can just be inside of a kotlin file.

So the difference would be in Kotlin

  object StringUtilClass() {
    fun shout(s: String) = s + "!!!""
  }

  import StringUtilClass.*
  StringUtilClass.shout("I'm mad")
vs

  fun String.shout() = this + "!!!"

  import StringExtensions.*
  "I'm mad".shout()
Kotlin doesn't always add brand new functionality, it also strives to make it faster to read and write code.

Re: Kotlin Is Better

#178

Post by grunca »

You can and should build your domain language on whatever base language you happen to like/use. This is where most failures happen on big projects. If you treat your solution as a script or glue code, and your complexity needs to scale, you will quickly reach a stalling point. A good, well thought structure & design is required,there is no language available (yet) that will replace that.

Re: Kotlin Is Better

#179

Post by seanwilson »

Singletoned wrote: post #154
seanwilson wrote: post #87

Earlier quoted context omitted.

> Changing one parameter or type on a class or function to refactor, and then just following the chain of compiler errors, reaching the end, and seeing that everything just works exactly how you want it to was a big eye opener to me. Yup, "following the chain of compiler errors" mostly makes refactoring straightforward. Dynamic typing is fine when the codebase is small enough to keep it all in your head so you know w…

We tend to use tests for just this case. You change anything you want, then see which tests break, and fix all the places. I definitely agree that dynamic typing doesn't scale as well as static typing, though.

> We tend to use tests for just this case. You change anything you want, then see which tests break, and fix all the places.

Why not tests + static typing? Getting tests to point out breakages is attempting to do job the compiler can do for you but not as well. If you renamed a field in some places but not others for example, you'd have to rely on good enough code coverage to catch this plus deciphering a failing test is nowhere near as easy as a compiler error that pinpoints the exact line causing the problem. Tests take time to write and static typing is giving you many tests for free. You also miss out on automatic refactoring tools and autocomplete.

Re: Kotlin Is Better

#180

Post by skrebbel »

fauigerzigerk wrote: post #172
cel1ne wrote: post #95

Earlier quoted context omitted.

If you got time, play around with extensions with multiple receivers, you can do pretty neat stuff with them. See my comment here: https://news.ycombinator.com/item?id=14365317

What's the advantage of extension functions compared to plain functions? fun String.shout() = this + "!!!" fun shout(s: String) = s + "!!!" Looks pretty much the same to me. Extension functions use static dispatch so what's the point of using member syntax? Also, extension functions can be overwritten by a member function with the same signature. That seems quite fragile to me considering the class and the extension…

Besides what Larrikin said, discoverability. Discoverability is the killer feature of languages designed for IDE support that you just won't understand if you haven't seen it. It's a big reason of why Kotlin beats Scala in practice, IMO (1).

I code Elixir a lot these days and spend a lot of time looking at hexdocs.pm and occasional library source code. With Kotlin or C#, this is seldomly necessary, because the IDE's autocomplete tells you everything you can do with this object. It doesn't guess, it knows. If it's in the list, you can do it, if it's not, you can't.

Now, if I have a string object called "str", and I write "str.", I want to see a list of everything I can do with it. But a MyStringUtils.shout() is never in that list, because it does not come after the dot.

With extension functions, this becomes possible with userland extensions to existing classes and interfaces. All you need is a single import on top, and good IDEs (eg. visual studio) can also auto-import that one if you use a function from it once.

(1) Last I tried, Scala was too slow to compile to provide 100% perfect autocomplete within a few milliseconds. IntelliJ did some Python-esque guesswork to mitigate that, but that effectively reduces the feature to "save me some keystrokes", i.e. not very useful. Maybe this has been fixed since.

Post reply on HN