In earlier days the same thing was said of compilers. That a good assembler programmer could always outcode the compiler. NOTE the keyword good! The problem is lack of good programmers!
Given that a requisite for the resources on this project ... is one or more years of Perl, it's likely that the Perl produced will vary widely from very bad to passable with the majority being indifferent. On Wednesday, May 7, 2014 2:54:06 PM UTC-5, Aristotle Pagaltzis wrote: > > * clueless newbie <li.han...@gmail.com <javascript:>> [2014-05-07 20:00]: > > Question given Marpa and the existence of a BNF for COBOL, can the > > problem of parsing COBOL and generating passable Perl be done? > > Without knowing COBOL in depth I’ll venture that strictly speaking, the > answer is, Yes, it is just a matter of sufficient effort. > > However, everything hangs on that “passable”. What is passable? > > You can, if COBOL is not particular crazy in some way, certainly produce > Perl code that corresponds mechanically to the original COBOL code. But > that Perl code will not look anything like code that a Perl programmer > would write. It will look like COBOL code expressed in Perl, because it > is – and not just in the trivially tautological sense: it will be built > on top of the exact semantics that COBOL code is, it will work exactly > like the COBOL code does that it came from. Short of a miracle, it is > not going to be a useful basis for refactoring it into *good* Perl code, > because all the choices for interfaces, abstractions and distribution of > responsibilities in the code were made when it was written in COBOL, all > of which you’d choose differently if you were writing Perl. Conversion > will just carry those over mechanically, because it cannot rethink them. > The only thing that can is called a programmer. > > Note that the consequence is that if you want to hire Perl programmers > to work on this code base you will not find them very effective, because > it won’t be written the way good Perl code is. > > So the question is what the project’s ultimate goal is. It is highly > likely that management is imagining it will achieve something that it > cannot, something much different from the very narrow kind of goal that > this approach is limited to. > > It is almost certain that the only way to achieve what management really > wants is a piecemeal rewrite of the system, by first breaking it down to > isolated components if need be, and then swapping them out over time for > rewritten pieces. It’s a lot of effort, but I know of no other approach > that has ever been successful. Conversions between radically different > languages never work, for the above reasons, and complete rewrites fail > because they are by definition waterfall projects, and almost always > beyond the scale where that model can work. The only hope for a rewrite > to succeed is to break it into chunks that can be finished and then > proven in the crucible of production use after finite amounts of effort > each, to get away from failure being an all-or-nothing proposition for > the effort as a whole. Even if the budget runs low before the conclusion > of the project, there are still working deliverables instead of a total > write-off. > > (Yes, in the absolute worst case this will require ultimately rewriting > every part of the system two or three times in order to get rid of all > the structures imposed by the original system’s design without changing > more than one or two pieces at a time. But there is no faster way to get > there, not successfully. The upside is that you get new code running in > production at each step along the way. I.e. it transforms “huge project” > into “long-term commitment”.) > > Regards, > -- > Aristotle Pagaltzis // <http://plasmasturm.org/> > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
