Live data from Hacker News

Kotlin Is Better

steve-yegge.blogspot.com

111–120 of 229 posts

Re: Kotlin Is Better

#111

Two thoughts. First, I also thought Android programming was horrible at first, but have since come to see it as no worse on average than iOS programming. The only really sucky thing about it IMO is the lack of ability to pass an object to another activity without serializing it (or maybe there is one I don't know about.) But since everything is done with fragments now that's moot anyway. Second, I tried Kotlin and li…

They did recently provide better APIs to address most of the Activity/Fragment issues https://developer.android.com/topic/libraries/architecture/i...

There was a talk about it on this IO https://www.youtube.com/watch?v=FrteWKKVyzI.

Re: Kotlin Is Better

#112
post #71
post #37

Earlier quoted context omitted.

> Sometimes they do exactly what you need, and 70% of the time they're just totally useless. I thought that but PyCharm scores way better than 70%. I even trust it to do automatic refactors. Sometimes... > The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light. Maybe I grew up on IDE's but I type stuff in full only if autocom…

They're different ways of programming -- it's where you spend your brain power. You can see codebases that weren't built in IDEs: they generally don't have strong naming conventions in their classes/structures/functions. One of my hobby projects is in C, and I prefer using an editor to an IDE. Because of an accident of history, public methods tend to be named like `P_PlayerCommandRead`, where `P` means (generally) "p…

More recently I've come to the conclusion that most of naming must be influenced by "how you grew up". As someone who has mostly touched the Java and Python ecosystems while learning to program, I frequently run into names that seem "weird" to me, because they replace often-used technical words (from those ecosystems) through more obscure synonyms.

C++ also often had that (replacing 'map' through 'transform' and so on) - but since it's a standard, at least it is usually more consistent in its own internal logic. Same goes e.g. for LINQ, which was influenced by SQL instead of LISP-like collection transformation functions.

Re: Kotlin Is Better

#113
post #55

Earlier quoted context omitted.

I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.

Two million line scala codebase -> 2 hour clean and rebuild with a top of the line workstation. IDE support has improved, compile times not so much.

Agreed as far as it goes. But can one person really understand a 2 million line codebase? Can a team large enough to use a 2 million line codebase stay in close enough communication that they all know what each other are doing? IME to stay sane on a codebase that large you need separated components with strict separation between interface and implementation and independent versioning of each, at which point you might as well make that split at the module/VCS level and take advantage of what your tools can do for you.

Re: Kotlin Is Better

#114
post #12
post #2

Why my programming languages are smarter than whatever dumb writer that knows nothing about my toolset and my needs is at hand with his trivial cliches.

> whatever dumb writer that knows nothing about my toolset I consider Steve Yegge to be one of the smartest writers I've ever read on the subject of programming. You might disagree, but I would recommend looking for his previous writing (which I'm not sure is still available). You may find he has a better understanding of your toolset than you presume. Or possibly not. I personally miss his rants.

He writes entertainingly (and clearly has a talent for the written word) but I'm not convinced he's got any genuine insight into programming. Put another way: he seems to be just as convincing when he's wrong as he is when he's right.

Re: Kotlin Is Better

#115

Earlier quoted context omitted.

You might have actually convinced people to not consider Scala. You are saying, Scala is great, except for these small things: 1. Modify your codebase to use microservices 2. Modify your IDE habits to be more REPL friendly 3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.

But the thing is if you modify your habits, it's so much more efficient than most other languages. It's reasonable to have to learn knew coding style when paradigm-shifting languages. Why isn't it reasonable for there to be other new behaviors as well?

Because there are other languages, which also provide the benefits, but without these downsides.

Re: Kotlin Is Better

#116
post #104

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…

Well, he/she isn't saying anything about smalltalk, but talking about python. Are you sure these two pose the same problems when it comes to automated refactoring? Apart from just lack of static typing, these languages could be miles apart when it comes to how dynamic they are and what problems this poses to automated refactoring. For example, the fact that attribute access in python can be delegated to a function th…

> I have no idea if smalltalk can do this,

It can.

> if my examples are good examples of showcasing the automated refactoring problem

They're not.

More to the point: Smalltalk is as dynamic a language as practically possible and was like that for two decades before Python existed. The `__getattr__` from Python, `method_missing` from Ruby, and `__index` from Lua are all inspired by Smalltalk's `doesNotUnderstand`. The concepts of metaclasses and first-class message sends was invented in Smalltalk. The idea of inspecting code using a GUI instead of flat text files also originates with Smalltalk. Refactoring, as noted by GP, also came out of Smalltalk-land. Smalltalk gives you all that without any static typing in sight.

How? Smalltalk is special. Normally, you have your code: a static blueprint of what's going to happen; and a program: part of computer memory which your code gets loaded into and gets executed. This is true for both statically and dynamically typed languages: the familiar type something -> hit "Run" -> see if it worked cycle works equally well in Java and in Python.

Smalltalk is not like this. With Smalltalk, all you have is a program. It's always running. You hand it the code and it patches itself dynamically in memory. The classes are live objects you can query. Metaclasses are, too, objects you can query. They implement methods for refactoring. It's easy, because there's no need for any parsing, statical analysis of any kind: you just iterate over all the classes in your system and ask them one by one: "do you call such-and-such method?" And the classes inspect themselves and say: "why, yes, I call it when handling such-and-such messages, here's the list".

Really, Smalltalk is special. It's not unique: Forth and Common Lisp come to mind, Self, Lua and Io too. But it's special and very few modern languages come close to its capabilities.

Re: Kotlin Is Better

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

Re: Kotlin Is Better

#118
post #74

Earlier quoted context omitted.

I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.

I work on a large Scala team. We use microservices so my regular compile times are somewhere between 4s and 20s. I rarely have to do a full rebuild. IDE support is bad, that's a good criticism but a good chunk of us don't use IDEs, and instead write it like a dynamic language. Live inside the REPL, copy paste back and fourth. As for 'subsets' everyone uses, I find this advantageous. Our team strongly encourages a pur…

IDE support with IntelliJ IDEA is now excellent, on par with Java and Kotlin. Everything just works, including automated refactoring and extractions.

Re: Kotlin Is Better

#119

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…

I agree. The Activity and Fragment lifecycles that create such a pain are based on architecture decisions, not language. Kotlin can't overcome the fundamental fact that activities are stateless, and all the knock-on effects this creates.

Re: Kotlin Is Better

#120

The biggest news is: Yegge is blogging again! Glad to see it!

As soon as I saw "blah blah blah (steve-yegge.blogspot.com)", I came looking for this comment. I hope he keeps it up. Also, apparently he actually "came back" back in November[1]. That post is even sort of related.

[1] https://steve-yegge.blogspot.com/2016/11/the-monkey-and-appl...

Post reply on HN