It would be nice if Mastodon's Android client weren't written and maintained by a crank who is unable to collaborate effectively or distinguish between good and bad dependencies. (Same problem, honestly)
Top-level
It would be nice if Mastodon's Android client weren't written and maintained by a crank who is unable to collaborate effectively or distinguish between good and bad dependencies. (Same problem, honestly) 30 comments
@gakisstylianos @billjings I have serious issues with his behaviour, but not with his choice of languages and libraries. Android allows for diversity of approaches, and (for me) is better for it. The same diversity that allows things like circuit, also allows his "unique" approach. I feel this diversity of approaches makes the platform different from Apple's stricter approach. @gakisstylianos @billjings What's abhorrent is his behaviour - choice of language, dumping on SkyDove's post, and behaviour on Mastodon Android repo. @gakisstylianos @billjings though the general rule of thumb increasingly seems like single contributor/decision-maker codebases suffer from this. People who were ahead of curve, but with no one to constructively challenge them, get stuck in their success. I get this smell from a bunch of other places, like whenever I look up issues or PRs on ktlint. @gakisstylianos @billjings Challenges aside, how do you expect anyone to want to contribute to this code if you have to constantly reinvent everything from scratch? @bladecoder @billjings oh yeah it'd be a pain for sure. I've seen an extremely similar situation for another company play out exactly this way after the original author left. Many years later, maintaining the Android app is a story of cycling through many Android devs who burn out and leave as soon as they are able to. While the app is obviously struggling to keep up with the product changes. @gakisstylianos @billjings whenever I browse the code of any "modern" Android app, I also ask myself the question why would someone put themselves through doing all that. You know, all those 6 abstraction layers to handle a click on a button. Those codebases remind me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition @grishka @billjings it's absolutely possible to build an unreadable monstrosity going the other direction too, I do not deny that. @grishka @gakisstylianos This is my most common complaint about sample apps we receive from candidates: they believe that "architecture" is what makes a good app. Totally ass backwards IMO And so they include a whole DI framework and all these repositories for a simple list->detail application. @billjings when I first came to mastodon, I planned to contribute to the official mastodon app on hope to fix some issues I saw. But when I reached the GitHub page and saw the anti kotlin manifesto (of sorts) I immediately backed away and even uninstalled the official app and hopped onto a more modern app maintained by people who actually care about the more important things @funkyidol @billjings this is all so wild to me because just a couple days ago I was like "hmm today I think I'll go fix+add some translations in the official Mastodon app" and then I was immediately so put off by everything I saw https://tech.lgbt/@mileskrell/112278952500397663 (I'm using that app right now, which alternative do you recommend?) @funkyidol @billjings megalodon's dependency on the official app (e.g. for translations) gives me pause, but thank you for suggesting it! I do like that it has extra support for glitch-soc features since the instance I'm on is running glitch-soc. definitely gonna keep an eye on it! @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. @billjings I guess it's not surprising that other clients are better, that kind of behavior drives away contributors |
@billjings I browsed the code and I must say that I don't know why someone would put themselves through doing all that. Is it all about feeling morally or intellectually "superior" to everyone else since they don't take "the easy way" of using even the most staple androidx libraries? I really am not sure.