Hi, I'm Thomas, chief developer of the SBTCVM project, and all around artist and programmer. I do have more of an understanding of balanced ternary than most i would say.
In my own experience, there are times that code gets to a point where major work is needed to improve performance, readability, and maintainability.
Think of it as remodeling your kitchen:
Removing a broken box fan from your house is easy, removing a wall from your house isn't. Obviously if your adding onto your kitchen, its not a bad idea to look into removing that wall between the kitchen and living room, because the kitchen is already going to be torn apart. Just as obvious, you would repaint your kitchen after the new walls and addition are plastered, not before.
Code's the same way. if you are planning some large new sections of code and dropping others, Obviously you don't want to rewrite something that's getting the boot. As well, knowing what those new sections need in older ones first, prevents you from refactoring code twice, or even 3 or 4 times.
With SBTCVM, a base 3 virtual machine project i run, I and the other project devs decided it was best to start a new codebase, as we wanted to redesign the architecture anyways. With that, it didn't make much sense to refactor the old codebase for python3, when we were working on its successor.
my point is, it depends on what you are planning right now. if you are going to write a new codebase, or massively overhaul your current one, planning your refactoring accordingly isn't a bad idea.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my own experience, there are times that code gets to a point where major work is needed to improve performance, readability, and maintainability.
Think of it as remodeling your kitchen:
Removing a broken box fan from your house is easy, removing a wall from your house isn't. Obviously if your adding onto your kitchen, its not a bad idea to look into removing that wall between the kitchen and living room, because the kitchen is already going to be torn apart. Just as obvious, you would repaint your kitchen after the new walls and addition are plastered, not before.
Code's the same way. if you are planning some large new sections of code and dropping others, Obviously you don't want to rewrite something that's getting the boot. As well, knowing what those new sections need in older ones first, prevents you from refactoring code twice, or even 3 or 4 times.
With SBTCVM, a base 3 virtual machine project i run, I and the other project devs decided it was best to start a new codebase, as we wanted to redesign the architecture anyways. With that, it didn't make much sense to refactor the old codebase for python3, when we were working on its successor.
my point is, it depends on what you are planning right now. if you are going to write a new codebase, or massively overhaul your current one, planning your refactoring accordingly isn't a bad idea.