3 ms·

(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,

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

keyle 2y ago
That makes sense. Thanks for the answer.
59nadir 2y ago
> 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.
- optymizer 2y ago
  We move fast and break things ;)
- redditor98654 2y ago
  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.
  - 59nadir 2y ago
    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.
    - redditor98654 2y ago
      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.
elAhmo 2y ago
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.
- onlyrealcuzzo 2y ago
  No, the translation is mostly automated.
- antirez 2y ago
  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.

keyle 2y ago

That makes sense. Thanks for the answer.

59nadir 2y ago

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

optymizer 2y ago
We move fast and break things ;)
redditor98654 2y ago
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.
- 59nadir 2y ago
  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.
  - redditor98654 2y ago
    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.

elAhmo 2y ago

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.

onlyrealcuzzo 2y ago
No, the translation is mostly automated.
antirez 2y ago
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.