Gregory's Server@billjings I wonder what @Gargron thinks about this
|
12 comments
 @billjings @saket why should I even care about other people's non-constructive opinions? You know, this whole "use Kotlin and follow The Google Way and don't you dare question anything" attitude can go both ways.  @grishka @billjings @saket So Jetpack Compose is bad, too, because it was created by Google? 🤔 Do you even know what a productivity boost Compose is? And you don't need to create thousand layers of abstraction... @svenjacobs @billjings @saket yes it is, to me. Objectively though, it's a different way to light up the pixels on the screen in the pattern you want. Not better, not worse, just different. Do you even know what a productivity boost it is to not give a crap about "new" technologies and just keeping on using same things you were using 10 years ago? With some iterative improvements maybe, like Java 17 instead of 6, but fundamentally the same things you've had ten whole years of experience with. @grishka Yes it is different and yes there are many ways and solutions to create Android applications. But regarding "not better", I would seriously challenge that. I think Compose is a cornerstone in Android development just like the introduction of Kotlin was. Just look how much you can achieve with less code. But I forget that you also don't like Kotlin, so I assume we will never be on the same page 😔 @svenjacobs it's a common fallacy to believe that "less code = better". Less code means more cryptic code, usually. Harder to read, understand, and debug. I simply like Java more. Modern Java. Lately, it introduces some of the same concepts that exist in Kotlin, but does so much more thoughtfully and such that they're easy to understand even if you don't know them beforehand. Like switch expressions or records or pattern-matching instanceof. And no forced null-safety nonsense, ever. @grishka Less code doesn't necessarily mean more cryptic code. Less code can also mean less boiler plate code, which makes code harder to read and understand. Why should final SomeObj someObj = SomeObj() be better than val someObj = SomeObj() Yes I know that Java has modern features and syntax, too, which some of them can be used for Android development. But I guess we could argue for hours, so just let's agree to disagree 😉 @grishka @saket Because life happens. People lose interest; people burn out; people die. I think it is horrible and inhuman to treat people like interchangeable cogs, but I also believe that if no one can pick up where you left off, that limits freedom of action for both of you in unpleasant ways. You choose each other, which is great, but you are also stuck with one another, which is not. @billjings @saket I'm not going to lose interest, I've already burned out from all the shit going on in the industry, and I believe in scientific advancements (and don't believe in the concept of "leaving behind"). @billjings @saket and by the way, this codebase can be maintained by anyone who knows Android SDK and Java — forks like Megalodon prove that. I don't *want* anyone who knows Compose but not views, or Kotlin but not Java, to contribute anything to any of my projects. I don't want to encourage the flawed modern top-to-bottom approach to learning programming. |
@saket @Gargron Well, he said he wouldn't tolerate anyone "insulting" @grishka, and then he blocked me, so... I guess there's your answer
Kinda weird! I figure @grishka can take it, right? You have to have pretty thick skin if you're going to write Android your own way like that.