How do you update your code for new programming languages?

I am not sure that "porting" code from an existing langauge to a new one makes any sense whatsoever (unless of course there is no mechanism for cross-language calling, or it is too inefficient). Many programming languages, even those that share similar "models" (e.g: object oriented, functional etc) have their own idioms etc ... "good" code is best expressed in the idioms of the language in which it is to be expressed ... As an example consider the error handling in Java and golang, one would never attempt to "port" from Java to Goland or vice versa since Java's exception model does not translate to Golang's "multiple return value with Error" model and vice versa...

Even before that, why create new languages when existing ones aren't even utilized properly? Most programmers I have seen coming from schools don't understand structured design practices or Data Structures. Many simply rely on the methods (functions) provided in the OOPs framework. the old phrase Garbage In Garbage Out, sums up the mostly bloated crap code that is very hackable today.

Currently, prompt engineering has made migrations quite straightforward for developers. Although extra efforts in code writing have been decreased, it is still important to understand why an update is necessary before stepping into a new stack. Due to the enticement of new technology, to assess scope, or to establish new objectives. Before starting, I recommend that you check the packages and compatibility for a consistent appearance and feel.

When choosing the target language its very important to consider the cost it will incur to train the team on the new language and whether the new language has wide adoption. When a language does not have wider adoption its harder and costlier to find developers.

Before choosing a language, let's think about what a programming language is. All things aside, it is just a tool. And a tool is as good as the value it provides. A language shouldn't be chosen just because it's new and popular. It should provide the whole team some kind of value. It can be more concise, it can support more modern libraries, its documentation may be easier to use etc. Finally, the team that is working on the code that's about to be updated should either have some prior knowledge about it, or the motivation to learn it.

1. Tech Advancements: New languages offer efficient features and tools. 2. Performance Boost: Modern languages improve application speed and efficiency. 3. Enhanced Security: Newer languages provide better built-in security. 4. Community Support: Wider communities aid development and troubleshooting. 5. Long-Term Maintainability* Ensures code longevity and adaptability.

Upgrading legacy code to a modern language is undoubtedly worthwhile despite the initial effort. Newer languages provide better readability, reliability, and security while enabling new features and optimizations that can future-proof functionality. With proper analysis of integration challenges, automated translation tools, and incremental validation testing, the risks of such a migration can be mitigated. The long-term gains in developer productivity, easier maintenance, and better user experiences justify investing resources into a language update. View it as an opportunity to refresh and revitalize your codebase. The benefits will speak for themselves.

When planning the update strategy, first check and ensure compatibility with external tools and libraries. Evaluate if the current framework has an equivalent in the new language. Make sure to map existing data structures to their counterparts and plan for any syntax differences. Update unit tests to ensure functionality in the new language. Decide on an approach for refactoring, set clear goals, and revise documentation accordingly. Implement version control, conduct code reviews to gather feedback, and have a plan in place to revert to the original code if unexpected issues arise.

Whether you're rewriting or refactoring, it's worth taking a few steps back to see what prompted the change of language. Since the new target has its own strengths, embrace them and transfer some of the complexity over to the language and frameworks used instead of writing a reproduction of existing code. The new target may enable new design patterns that better suit the codebase. Also, it's good to make sure everyone involved with the project gets familiar with the new language. This will prevent regressing to "basic control flow" that is possible in any language and thus avoid excessive code verbosity.

Having a good testing process is essential when you want to do major refactors. Otherwise there's no guarantee that you're not breaking existing functionality or modifying expected behavior in unintended ways. Even if switching to an entirely new language, you should try to take advantage of your existing test suite while working on the migration. There's no reason that refactoring or rewriting a codebase should be a daunting task, strive for incremental changes and leverage your existing code as much as possible.

Since I mostly write hardware drivers, a "new" language is mostly irrelevant. You need to know assembly language even if you write in "C". Al "modern" languages rely on huge libraries and run-time environments which assume that the operating system works - but the OS again depend on thes drivers!

This is very true; always test and debug your code. Even your projects always try to include these best practices, and they help you become a better engineer. The last thing to add is that our IDEs are brilliant, and with AI, it's now effortless to write or learn how to write tests if you are struggling with the concepts.

Every time I see people writing codes, I ask where the tests are? People tend not to write tests thinking that will cost time and cost resource efforts. Sometimes they're considered unbilled efforts. But it becomes a horrible experience when there is a requirement for refactoring or upgrading. Even adding some additional features can break code let alone the refactoring. So often I see people spending time happily to test the codebase for any breaks after doing a few small refactoring which could have been automated with unit tests and various other types of testing strategies. Now where is their excuse of wasting time? Write testable codes and tests even if you don't like to write them.

One lesson I've held close throughout my coding journey is the significance of writing testable code. When code is structured with testability in mind, it allows for individual components to be easily verified and validated. This approach not only streamlines the debugging process but also enhances the overall reliability of the software. By emphasizing testability, it becomes straightforward to spot and rectify any issues during updates or modifications. In essence, testable code ensures a robust foundation, making it easier to build upon and adapt as needed. Testing isn't just about catching errors; it's about validating the choices I've made in my code and giving me the confidence to move forward.

Testing the code after every major refactoring is crucial! It is also very important to use a version control tool like Git, so that you can always go back to an older version of the code, if a refactoring caused you major problems.

Before making changes to your code, it's essential to test and debug it. This helps catch and fix issues, making the process of improving and transforming your code smoother and more dependable.

This is interesting. I'd say review (and documentation, too) must be done IN the process of code conversion, not AFTER it. Otherwise it won't happen, or will be less efficient - because of the sheer amount of code to review, and the long feedback loop.

before deploying code we should have team Demo and feedback for any scope of improvement BDD (behaviour driven development ) can solve the user pain points. having BDD, BRD documentation helps in logic and purpose to write code.

Peer reviews play a central role in this process. Feedback from others provides fresh perspectives and insights I might have missed. Alongside, a well-maintained changelog is like a story of the code's evolution. I make it a point to articulate the reasoning, logic, and any alterations from the original version. A well-maintained codebase is not solely determined by its operational performance but also by the collaborative efforts behind its review and documentation.

By thoroughly reviewing your refactored code, you gain greater confidence in its correctness. This confidence extends to the deployment phase, reducing the likelihood of introducing new bugs into the system. Additionally, well-documented pull requests serve as a knowledge-sharing resource for both current and future team members, making it easier for others to understand your changes and make informed contributions.

The code should be so clear that just by reading it one should be capable of getting a grasp on what it does. It should be self-documenting. For instance, the varaibles and constants names should be meaningful, the instructions should not be redundant, the code should be properly split in specialized classes, methods and functions, etc. Only the information that cannot be easily inferred by the code should be provided in inline or block comments and docstrings. After this the remaining info (e.g., HW schematics, lab pictures and similar can be provided into README files)

?? For code maintenance and deployment, my preference is Bitbucket due to its versatility. ?? Bitbucket facilitates easy code deployment on various platforms such as AWS, Google Cloud, Heroku, etc. ?? It seamlessly integrates with DataDog, allowing developers to access metrics for effective scaling in response to anomalies. ?? Sentry is my preferred tool for real-time bug detection, providing robust monitoring and analysis capabilities. ?? When working in teams, leveraging WebHooks integration strategies ensures efficient communication of issues and warnings.

Deploy it on collaborative sites such as GitHub, or for the very least, use a git repository. That allows maintenance of code versions and updates easier to manage, and prevents potential mishaps related to work getting lost etc.

I agree with some posts here that you shouldn't necessarily prepare your code for new programming languages. What you should do is ensure consistent coding standards across the organization. The KISS principle comes to mind here. As your organization adds more languages, code, tools, etc, the technical complexity explodes. Keeping your toolkit deliberately small and not immediately reaching for third-party solutions prevents a large majority of tech debt. This allows your platform or DevOps engineers to create CI/CD tooling that is straightforward and simple to adopt across the organization. However, context is critical here. When software is mature, it's important to add tests to smooth migration processes and maintain reliability.

Moving to a new programming language is hard, and most likely it will be hard to get it right at one go. In that case, in my opinion, the best approach is to follow an A/B Testing pattern. You can open the new version for a certain percentage of your users, and parallelly keep running the legacy version too. In this way if anything goes wrong all of your users won't get hampered, and you can quicky migrate the affected users back to the legacy system until the issue with the new version is fixed. Also use proper logging so that you can identify the logs coming from different versions of your software. This will help u figure out if the newer version is behaving differently than the older system in any way.

Implementa el código actualizado en tu entorno de producción y monitorea su rendimiento de cerca. Además, asegúrate de mantener el código regularmente, aplicando parches de seguridad y realizando actualizaciones según sea necesario para garantizar su funcionalidad continua.

Code is executable representation of a software design. So to update an existing code to a new language the following steps are useful. 1. Ensure you have a good design 2. Study the new language to get the best fit code pattern for your existing design 3. Make the necessary updates 4. Test the code with existing black box test cases.

I really feel that many of these questions are auto- or AI-generated, because there are so many very similar questions that seem to just combine two or three concepts somewhat randomly and in mostly nonsensical ways, when you think about them practically.

What if there were one generic tool, using Gen AI, that: 1- Analyses the Assembly language of any old software 2- Documents all use cases and workflows in design diagrams and unit tests 3- Optimizes and reduces any unnecessary use cases that are never reached, cause the assembly code will present us with plenty. Perhaps it asks feedback from product managers directly through those design diagrams if some use-cases are still relevant today / can be done better 4- Outputs the app code in an intermediary descriptive programming language, to allow easy conversion to any language 5- uses that intermediary language to convert to any modern language of choice

Try to make sure that you record the results that were occuring previously in the old piece of code, so that they can be compared to in the updated code. Try to also note down the expected outputs vs. actual outputs, as that will help others reading your documentation on the update process

I would start with what was performance of the code which was running before and if it's improving with the new changes, how it's impacting the product. If it's improving code quality & also the performance I will update with the new version . Refactoring the new functions with lesser lines of code, with implementing security to it will be best way to hop from one to other.