3 ms·
Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it
by drzaiusx11 5mo ago
Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it's best to start with a mechanical translation, literally bug for bug, leaving shit exactly as I found it (just in another language.)
I've done Perl to Java, Java to Kotlin, Python to Ruby, Ruby to Java, C to Swift, you name it.
It's only when you change behavior during the rewrite that it becomes an intractable problem. If you ship a 1:1 translation, THEN you can start going through the list of "bugs" you found along the way. Tread carefully when it comes to this, however, as I can almost guarantee that within your non-trivial codebase there will be some code that implicitly _depends_ on a "bug" to function at all. This where shit hits the fan.
- inamorty 5mo ago"Load bearing bugs"
- drzaiusx11 5mo agoIt really is incredible how frequently these occur in everyday codebases of sufficient size.
- svieira 5mo agoWe actually have a constant in our codebase to mark such bugs. You found one? Put it inside an: if (PREFER_EXISTING_BUGS_TO_NEW_ONES) { theOldBehavior(); } else { theNewBehavior(); } Then, if we ever go to do a v2 of the thing, we can review these existing "load bearing bugs" and see if they make sense to change.
- drzaiusx11 5mo agoWe do this via feature flags as well whenever "fixing" a non-trivial bug