7 ms·
This would really useful if it worked with legacy code. For example, you could migrate all that COBOL code into Java or Python, or all the Fortran scientific co
by cfn 3y ago
This would really useful if it worked with legacy code. For example, you could migrate all that COBOL code into Java or Python, or all the Fortran scientific code into C++ or Python.
I tried to migrate a twenty year old Visual Basic 6.0 project to c# by doing it piecemeal with GPT4 and it failed completely. Both in the UI and the backend. I am keeping my fingers crossed for a GPT n+1 that actually can do this.
Incidentally, I found out that GPT4 (as in chatGPT) is very useful if you need to program in VB6 which is nearly absent from search results these days.
- codeonline 3y agoWhen you say it's failed completely what do you mean? I've been translating between c# and python and having a great deal of success at the function and class level. I even ported unit tests easily between xunit and pythons unittest library. I've got close to 100% test coverage so I'm fairly confident it's done well
- throwawayadvsec 3y agotranslating between popular mainstream languages is not usually an issue. translating a 20yo project written in a language that isn't used much anymore is a lot different
- fomine3 3y agoWe should upload VB6 projects to GitHub.
- lionkor 3y agoaren't the tests also written by chatgpt then?
- still_grokking 3y agoBut they are confident everything is done well! The code looks good, and that's a great success. What else would you like?
- lionkor 3y agoship it.
- cfn 3y agoFailed as in it produced not working code that would take longer to fix than if I re-wrote it myself. Or, in the case of user interfaces, the generated UI code simply was useless and did not even resemble the original UI.
- transitivebs 3y agoagreed. I'm guessing the limiting factor here is training data w/ code from these languages that aren't as well represented in OSS
- wouldbecouldbe 3y agoI think at this stage there is no project GPT is going to do faultless, it's more like a boilerplate conversion. Will save you time, but needs a lot of writing after, it wont be able to properly link dependencies, and overview an entire project at this stage, even if it's alone for the max-token limit. But the did a nice job in this project addressing some of the issues.
- staunton 3y agoGPT would be a lot more useful if it were able to mark sections where it "isn't confident that it can do well". Another thing would be an iterative approach that includes compiling and testing the code. Essentially, you want to build an artificial programmer ("junior dev") who can work with a better developer/manager. That seems to be the way in the short-term. Doing this by just single-shot text transformation is a lot harder. Humans can't really do that neither.
- tylercrompton 3y agoWouldn't it be easier to convert VB6 to VB.NET and then convert that to C#? The latter conversion is mostly just a find-and-replace operation, as I understand it.
- kwhitefoot 3y agoSounds like you haven't tried doing it. V6 and VB.Net are fundamentally different languages. VB.Net has much more in common with C# than it has with VB6. It is the conversion from VB6 to VB.Net that is the hard part but it is probably no harder to convert directly to C#. In particular the way that object destruction works is completely different. VB6 using reference counting and .Net languages use a garbage collector. Systems using reference counting destroy objects and run the destructors as soon as there are no references to the object while those using garbage collectors might only dispose of the objects when memory is low, perhaps never. This means that object lifetime can be very different and that patterns such as RAII require extra work in .Net.
- fomine3 3y agoThat's true but was VB6 programs seriously made about memory and resource management? I think it should be modernized anyway when upgrading.
- kwhitefoot 3y agoOf course they were. We wrote optimizers in VB6 that used serious amounts of memory and controllers for hardware that required careful control of resources. What exactly is more modern about a system that does not have deterministic finalization as part of object scope?
- skissane 3y agoThe other day I was trying to translate some old Fortran 77 code to C. I tried asking ChatGPT to do it. It looked good on the surface, but it had subtly mangled some of the if conditions, etc, which resulted in it producing completely different numbers from what the original Fortran code did. Then I remembered good old f2c, and I tried using that. Unlike ChatGPT, the code f2c produced was (as far as I can tell) correct, albeit a lot uglier. But it is a lot easier to refactor ugly-but-correct code into nicer-and-correct code, than incorrect code into correct code.
- Szpadel 3y agoyou could try providing gpt original code and ugly C, and ask it to refactor. In my experience gpt is fairly good in code refactoring
- deleted 3y ago[deleted]
- YeGoblynQueenne 3y ago>> This would really useful if it worked with legacy code. For example, you could migrate all that COBOL code into Java or Python, or all the Fortran scientific code into C++ or Python. Having done a year-long stint at a mainframe team in one of the large financial corps (no, bigger than that) I can assure you that this is never going to happen for COBOL-to-java (or to-anything) unless there are strong guarantees of 100% correctness. See, one of the first things they tell you when you join a COBOL team is that you don't touch the code, unless you've filed a form that explains every detail of the change you want to make and why. In the team I worked for, that was a 10+ page Word form that would put a herd of elephants to sleep with its obstinacy and recalcitrance. And that was only to change some JCL scripts- the scripts that run the COBOL jobs. Nobody dares to change now 50-years old COBOL code. Because every time they do, the corp loses millions. So I was told by those who knew better than me, and had been doing that job all their lives. Bottom line, until someone figures out how to transform a gigantic, half a century-old COBOL codebase into java without breaking nothing at all, there's not gon' be any migrations. I get a feeling that the requirements for scientific code are going to be much looser, and that this is going to cause a whole lot of mayhem, on the other hand.