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

211–220 of 229 posts

Re: Kotlin Is Better

#211

Post by [deleted] »

fauigerzigerk wrote: post #201
cel1ne wrote: post #199

Earlier quoted context omitted.

I used extensions with multiple receivers for adding context inside data-structures. Example: I have a layout-algorithm for a grid that takes sections: interface Section { val title: String fun something() } Then I have the grid-algorithm. Inside I store expanded/collapsed state for each section. When I use a member-extension with both receivers I can write that pretty conveniently: class GridLayout(sections: List )…

This looks neither clear nor convenient to me.

[deleted]

Re: Kotlin Is Better

#212

Post by cel1ne »

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…

Members can be chained, which improves readability a lot.

Re: Kotlin Is Better

#213

Post by cja »

_ivvf wrote: post #147
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…

I developed at a Windows-centric shop for several years using C# and Visual Studio, and I can personally attest, at least in 2013, that stock Visual Studio is pretty far behind Java IDEs in its capabilities. At the time everyone I talked to recommended I get my manager to get me a copy of ReSharper, but it wasn't in our team's budget. At least in 2013, here's where I remember C# IDE support was lacking: * No automati…

My bosses never understood ReSharper so I bought it myself. Worth it just to reduce my frustration at work.

Re: Kotlin Is Better

#215

Post by r3m3mb3rm3 »

MarkMc wrote: post #209
r3m3mb3rm3 wrote: post #129

Earlier quoted context omitted.

Honestly, I can't think of anything that is not bullshit. Having to declare a new variable for each parameter that you need to manipulate makes the code a lot messier.

It's a trade-off. Yes, the code is messier for the 20% of functions where the input is manipulated. For the remaining 80% it makes it slightly easier to analyse the behaviour of the function.

I understand that. But I think it's better to let the programmer decide whether their parameters are mutable or not. Then you don't have to compromise.

Re: Kotlin Is Better

#216

Post by irishsultan »

mpweiher wrote: post #186
irishsultan wrote: post #170

Earlier quoted context omitted.

This may depend a lot on coding style and uniformity of coding conventions, something likely to be the case on the Smalltalk system (as it was designed by a small and focussed team) and less likely to be the case on a system using many different libraries, some of which might have names conflicting with names you use. Even then you still need manual supervision in that it may work in 99% of the cases, but for a parti…

Yours is first and foremost a theoretical argument. The authors of the Refactoring Browser and I understand these theoretical concerns (about not having static type safety). However, there is theory and there is practice. The two are not identical, and practice trumps theory (see also: science). And in practice, that theoretical concern appears to not have been an issue. You also argue with hypotheticals (may...depen…

> You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so?

Partly because my experience with Smalltalk has always been that my experience is less positive than what others claim to encounter (this is not just about refactoring, where at least once I wanted to rename a method, but this method name was also used in a different context where it shouldn't be renamed, typing would have made this irrelevant; but also about things like Monticello where I got far more conflicts and things that didn't work out of the box than I consider reasonable or knew how to handle). This may have been the way I got introduced to the platform, but it colors my skepticism about the generality of the observations.

Re: Kotlin Is Better

#217

Post by vram22 »

barrkel wrote: post #19

Other language built around IDE support: Delphi. The compiler was built with callbacks to provide code completion; it runs in process, as a DLL, as part of the IDE. No accident that Hejlsberg also design C#, and innovated further with TypeScript's language server. He wrote the original Turbo Pascal (IDE + Compiler in the same executable) in assembler, so he's been building IDE + language combos all his life.

I've read somewhere (much earlier) that some of the early Borland products were written in assembly language. That's why they were so fast.

Re: Kotlin Is Better

#218

Post by dahauns »

mpweiher wrote: post #188
hota_mazi wrote: post #183

Earlier quoted context omitted.

> > (and yes, that includes Smalltalk IDE's) > Patently false. It's a mathematical fact. Without type annotations, refactorings are never safe and need supervision from a human. Did you notice that the "Refactoring Browser" calls itself just that, not "Automatic"? Because it can't provide that guarantee. Even renaming a function is dangerous and can break a program when you don't have type annotations. I have a lot o…

> Without type annotations, refactorings are never safe There is a difference between "I can prove this is safe" and "this is safe". You guys need to start figuring out the difference between theory and practice.

In practice, "this is safe" often transforms to "I thought this was safe" at the most inopportune moment.

Re: Kotlin Is Better

#219

Post by dahauns »

pkolaczk wrote: post #135
cryptos wrote: post #127

Earlier quoted context omitted.

I've used IntelliJ for Scala some time and did encounter way more IDE bugs than in Java. I think JetBrains did a good job, but Scala is not engineered towards tool support. That is one big flaw of the language. Kotlin is much more pagmatic (not only) in this regard, what is no surprise coming from a tool vendor.

I also encountered way more IDE bugs in Scala than in Java. Actually during the full last year of development of a real-world commercial Scala project I encountered 0 bugs in Java and 2 bugs in Scala. What about more objective measures? Scala plugin issue tracker: 11667 issues. Kotlin plugin issue tracker: 17664 issues. And this difference is despite Scala being longer on the market and being more popular than Kotlin…

How on earth is this an objective measure for plugin quality? There's so much you can interpret into these numbers that they are borderline meaningless.

Re: Kotlin Is Better

#220

Post by emodendroket »

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.

But if you're writing tests (and writing documentation that documents the expected return type of methods, etc.) you're doing an error-prone replacement of work the compiler can be doing for you.
Post reply on HN