Hacker News Reader

Comment by optymizer | Hacker News Reader

(Android dev at Meta here, though not involved with the Kotlin migration. Opinion below, completely my own)

We have: public and internal apps, tests for those, tons of wrappers around Android APIs, autogenerated infra code, did I mention the API wrappers?, custom layout engines, duplicate code that people wrote because they couldn't be bothered to search the monorepo, code that was copied without much thought because people searched the monorepo and found something, app architecture tools like dependency injectors, annotation processors, custom build tooling, etc

If you can think it, someone has probably committed Java/Kotlin or native code for it already.

View on HN

> duplicate code that people wrote because they couldn't be bothered to search the monorepo, code that was copied without much thought because people searched the monorepo and found something

This is also a very common way in Object-Oriented code bases to ensure you're not messing anything up by re-using classes. Concatenating yet another class to the code base is the safest and laziest way to ensure you're not possibly changing the behavior of anything else when you inevitably need to add/change something in the class.

We move fast and break things ;)

Why is this a OOP problem and not a problem in large code-bases in general? I can easily see it happening in functional or imperative languages where one creates an almost identical copy of a function instead of reusing and modifying an existing one.

While the reason people would be scared of modifying a class and a function could be the same, the way this defensive copy-paste of code would pan out is not the same; in one case we get an entirely new class, with all its nonsense in it (in many cases), in the other we get a new function operating on the same data types.

The former is not how OO is supposed to really work, but it is a direct result of adopting OO (non-obvious results of inheritance and other features) and in the latter we get exactly what we already were doing: Lots of functions operating on data, it's just more of the same.

It seems to me that one of these highlights the failure of its respective paradigm much more than the other.

I should note that I don't think functional programming as a paradigm is a particularly fruitful one. What I'm arguing for in the large, if anything, is bog standard procedural/imperative code with procedures/functions + data. Sprinkle in the few useful ideas functional programming does offer and you have something that has a fighting chance.

I don’t agree. What do you mean by all the additional nonsense if a class.

This sees to give an unreasonable leeway to copy pasted code to imperative functional languages. What if the copied function also has side effects, mutates a global variable etc. All these problems still exists.

Wouldn't it make more sense to do a massive refactoring given the situation is as you described? And, if needed, rewrite to Kotlin later. This would just cause the same problems to be reproduced in a different language.

No, the translation is mostly automated.

A rewrite, too, would take less than years, would have a better end result. Honestly the FB application is not exactly rocket science, and the massive amount of code they have points more on the direction of broken internal process and a total lack of simplicity in the design and choices.

That makes sense. Thanks for the answer.

Reply on news.ycombinator.com