Live data from Hacker News

Kotlin Is Better

steve-yegge.blogspot.com

201–210 of 229 posts

Re: Kotlin Is Better

#201
post #199

Earlier quoted context omitted.

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

Re: Kotlin Is Better

#202
post #140

Earlier quoted context omitted.

I often use WebStorm (Intellij variant), and I am continually annoyed by its inability to keep up with my typing. I do like the IDE, but I do wish it was more responsive. It often feels like a heavyweight, taking long to do any operation, especially starting up.

I've never seen anything that tried to do intellisense in JavaScript that wasn't slower than molasses. The quickest way for me to get Visual Studio to crash is to open two or three small .js files, watch the memory usage skyrocket, and the editor speed grind to a halt.

I use it for dart

Re: Kotlin Is Better

#203

A few people have said that IntelliJ is slow. Why is this so, if Java is not inherently slow? Sure JetBrains are some of the smartest developers around and yet their IDE is still slow. I can't help but feel that Java is slow and problems with performance in something like IntelliJ do nothing to dispel that feeling.

Netbeans is written in Java and is pretty fast.

Java is objectively not slow. Unless slightly slower than C/C++ is what you call "slow"

Re: Kotlin Is Better

#204

Yet Another Java Rant. In my book, Java is a fine language, and has been since Java SE 6 was released back in 2006. It keeps getting better, too. "Glacial" pace or not. Whenever any kind of discussion about Java comes up, people start ranting about XML configuration or annotations. These are not language problems. These are developer problems. If you don't like XML or annotations, then don't use them. Problem solved.…

I've also been coding Java professionally for 17 years and like you I feel Java is a great little language. What makes the biggest difference in productivity is the simplicity of the algorithm and associated object oriented design, and I've never really felt that Java was hindering me in achieving that simplicity.

I wonder how well the like/dislike of Java correlates with like/dislike of object-oriented programming. I've always loved object oriented programming but there seems to be many programmers who feel the opposite, and for them Java would be going against the grain.

Re: Kotlin Is Better

#205

Earlier quoted context omitted.

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

Here's the thing: guided, interactive refactoring is not the same as automatic refactoring. If I can hit a button to inline all usages of a method (as in IntelliJ), that's not the same as using a tool that can point out candidate locations for inlining what might be the method. Furthermore, the reason Smalltalk pulled all this off is because it is/was metadata-heavy. Every object could be interrogated about its shape…

> Clearly this is not the case for Python, Ruby, or Javascript,

Javascript objects are inspectable and modifiable in exactly the same way as Smalltalk objects are. All browsers support this today.

This inspection capability has nothing to do with static/dynamic typing.

> So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.

Yes, they are. You can do anything with IDEA/Eclipse + Java that you could do in Smalltalk + IDE.

Re: Kotlin Is Better

#206

The only problem with Steve's rant is that he starts out describing his experience with APIs, but then it turns into an issue of better languages. Presumably Kotlin doesn't wrap the entire Android API with some kind of better API, but most Android API calls would be direct Kotlin->Java calls, so how does Kotlin solve the nasty API issue? Really, this seems to be another Java critique by Steve. He's also written criti…

Well, he does say this:

> but now with Kotlin I'm finding Android programming is, dare I say it -- enjoyable? I think this suggests that Android's "bad" APIs weren't all that bad to begin with, but rather that Java has been masking Android's neat functionality with a bunch of Java-y cruft.

Re: Kotlin Is Better

#207

A few people have said that IntelliJ is slow. Why is this so, if Java is not inherently slow? Sure JetBrains are some of the smartest developers around and yet their IDE is still slow. I can't help but feel that Java is slow and problems with performance in something like IntelliJ do nothing to dispel that feeling.

IntelliJ is written in Swing, which 10 years ago was certainly slower than an alternative UI framework like SWT. Not sure if there is a noticeable difference nowadays.

Re: Kotlin Is Better

#209

Earlier quoted context omitted.

There's got to be a good reason why though?

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.

Re: Kotlin Is Better

#210
So this guy has [0]:

. advocated Javascript on the server-side

. tried to get goog to support Ruby

. is active in Lisp, enough to get it mentioned in wikipedia twice

And now is enough of an expert in Java and Koltin to instruct us on which is "better". That's a lot of languages to be an expert in! It's almost unbelievable.

If someone who's been working in Java for years and then has done a significant Koltin project (100k plus SLOC) that's in production and they told me "Koltin is ?" I would listen to them. Otherwise I might be tempted to believe someone's writing another clickbait article.

Regardless, looking to his wiki history, it seems he's, charitably, outspoken. Not someone i'd look to for a sober technical analysis.

[0] https://en.wikipedia.org/wiki/Steve_Yegge

Post reply on HN