3 ms·

1. Unconsidered edge cases? We'll have to find out... We can always change the _source_ code to eliminate known unhandled edge cases. 2. We ourselves are heavy

by _veelo 8y ago

1. Unconsidered edge cases? We'll have to find out... We can always change the _source_ code to eliminate known unhandled edge cases. 2. We ourselves are heavy users of our software, and are likely to be the first to discover "oddities". More serious are subtle numeric differences, and we'll have to create tests against that. One approach to validating the transpiler is instrumenting the code. We could write a Pascal-to-Pascal transpiler that inserts extra code, for example logging the return value of every function. If we do the same for the Pascal-to-D transpiler, and do an identical run, we can compare the logs. And variations of that approach. 3. If a small percentage is unproportionally hard to translate mechanically, we can isolate that and translate manually. 4. I fail to see what you are getting at. 5. Of course we can link code. We think the community is wide enough for us. 6. You mean it gets passed to C. Thanks for the suggestion. We have a working dual language situation with C++, we don't see that as an attractive option for our other tools. Why would Python be better than D?

scj 8y ago
I think point one is the concern of most people on this page. The most I've ever transpiled is 40kloc (this was for an R&D project, I'd think twice before doing it in production). ~500kloc is a different matter. What % of the codebase are you familiar with? What % of the code is known by your team? If you had multiple, conflicting errors pop up at once, how much effort would it take to isolate them (not fix, just identify). What about in a section where no one has worked in a long time (assuming such a thing exists)? Like any old codebase, I'm sure there are functions that have "just worked" for years (or in this case, decades). With a single action, every piece of code that's been proven solid over time is about to be suspect. For point two, I think you have a lot more confidence in your ability to detect problems than I would in your shoes. For point three, I'd much rather manually port necessary code piece by piece over a period of years. Unit testing like crazy while doing so. Thanks to linking, this is an option... One I'd recommend. Point four is similar to majormajor's comment about the aftermath of the switch. I'm attempting to project beyond the immediate... This port could become a whipping boy... That could bleed into political fallout. No matter what technology you introduce, people will complain. Doubly so if problems arise. Adding a custom transpiler on top of that increases the risk significantly. The easiest transition path to a ${NEW_LANGUAGE} is through linking. I'm not sure about Python vs. D. My instincts are towards the former, especially if I'm supporting SEM (STEM minus the T) grads as programmers. I also wouldn't easily write off interpreted languages (I'd rather work with them when possible). I think you have your heart set on this path. But losing the binary safety net in favour of a bespoke transpiler is not a gamble I'd make with large amounts of production code... Good luck!

by _veelo 8y ago

scj 8y ago

I think point one is the concern of most people on this page. The most I've ever transpiled is 40kloc (this was for an R&D project, I'd think twice before doing it in production). ~500kloc is a different matter. What % of the codebase are you familiar with? What % of the code is known by your team? If you had multiple, conflicting errors pop up at once, how much effort would it take to isolate them (not fix, just identify). What about in a section where no one has worked in a long time (assuming such a thing exists)? Like any old codebase, I'm sure there are functions that have "just worked" for years (or in this case, decades). With a single action, every piece of code that's been proven solid over time is about to be suspect. For point two, I think you have a lot more confidence in your ability to detect problems than I would in your shoes. For point three, I'd much rather manually port necessary code piece by piece over a period of years. Unit testing like crazy while doing so. Thanks to linking, this is an option... One I'd recommend. Point four is similar to majormajor's comment about the aftermath of the switch. I'm attempting to project beyond the immediate... This port could become a whipping boy... That could bleed into political fallout. No matter what technology you introduce, people will complain. Doubly so if problems arise. Adding a custom transpiler on top of that increases the risk significantly. The easiest transition path to a ${NEW_LANGUAGE} is through linking. I'm not sure about Python vs. D. My instincts are towards the former, especially if I'm supporting SEM (STEM minus the T) grads as programmers. I also wouldn't easily write off interpreted languages (I'd rather work with them when possible). I think you have your heart set on this path. But losing the binary safety net in favour of a bespoke transpiler is not a gamble I'd make with large amounts of production code... Good luck!