“Why don't you just rewrite it in X?”
Every time a new programming language becomes popular, its loyal fans extol its virtues to the skies and try to turn people into their cult, sending a report to existing projects about bugs with the following content:
“Hi, I noticed here that your project was written in [the X programming language]. You should rewrite everything in Y because it is better in terms of Z function. Thank you-bye! ”
Outlined in this form, the proposal seems not at all difficult. Since the Z function is better, then, of course, everyone should immediately rewrite their projects on Y.
')
Recently, there has been a tendency to convert tools used by various software projects in the Gnome stack from a mixture of shell, Awk and Perl to Python 3. The main argument in favor of this transformation is that when a good modern project has only one “language” dependency, the application is easier to compile using Gnome technologies on platforms such as Windows. The transition from project to project also becomes easier.
One of the tools that undergo this transformation is GTK-doc , a tool for generating documentation, written mostly in Perl. I worked on converting it into Python 3 along with the team of creators. It was an instructive experience in many ways. First of all, it turned out that the conversion between any two languages usually falls into three phases:
Converting Perl to Python in the case of GTK-doc is relatively simple. Work is conducted mainly with regular expressions, arrays and dictionaries. All these three types of entities behave almost equally in both languages, so the first phase for the most part boils down to purely mechanical work. The second consists of correcting all errors and behavioral changes made during the previous stage (many are caused by typing errors and inattention when performing the first step). In essence, this is a debugging phase. The third step is to convert regular expressions and global variables into objects and other normal and readable constructs.
In implementing the conversion, I was mainly engaged in the first step, and the developer, who led the project GTK-doc, agreed to complete the work on the second and third steps. In the process of converting 6000+ lines of the gtkdoc-mkdb file, I made some measurements, and it turned out that I can convert with a maximum speed of 500 lines per hour, that is, a line of code takes about 7 seconds. I achieved such results only if the code was simple to convert and all the work was reduced to training for typing speed in Emacs. Periodically, there were more intricate features of Perl, and on these fragments the pace of work slowed down by 10, 100, or even 1000 times. And if there were ports there that would need to change the architecture (this happens, for example, when converting from a more flexible language to one where the compiler checks the lifetime of the objects), they would take even more time.
I don’t know how time-consuming the second and third steps were, but if you recall some comments that flashed in the chat, I think it’s quite. According to the most optimistic calculations, the speed of work on these three types of elements was at an average speed of 250 lines of code per hour.
And now the saddest thing. With such speed it is impossible to carry out the conversion on an ongoing basis Manually translating code from one format to another is the most boring job imaginable; it is devastating and morally killing. I could not do it more than a few hours a day - at some point I started to ruffle in the eyes of dollar signs, semicolons and various brackets. Based on this, you can estimate that the conversion speed, which the developer can consistently maintain, working alone is about 100 lines per hour (I doubt that even this is real if the work on the project will last for several weeks, but there are no measurements, so we lower this consideration).
According to Ohloh, the cURL project consists of approximately 100,000 lines of code. If we assume that the conversion between any two languages is no more difficult than between simple Perl and Python (which is unlikely), then the whole process will take 1000 man-hours. That is, five months full-time work with an eight-hour working day. And when you're done, you have to transfer all the changes that were made during the conversion. Stopping work on a project while you are translating from one language to another is not an option.
From all this a clear and simple answer emerges to the question: “Why do people simply not translate the code into another language?”.
"Just rewrite language X" is impossible.
PS There are tools that convert from language to language automatically. They can help, but only in the first stage. The second and third stages remain on your conscience and may take longer because the manually converted code is clearer to people. The theory of completeness in Turing hints to us that everything is very bad.
“Hi, I noticed here that your project was written in [the X programming language]. You should rewrite everything in Y because it is better in terms of Z function. Thank you-bye! ”
Outlined in this form, the proposal seems not at all difficult. Since the Z function is better, then, of course, everyone should immediately rewrite their projects on Y.
')
Recently, there has been a tendency to convert tools used by various software projects in the Gnome stack from a mixture of shell, Awk and Perl to Python 3. The main argument in favor of this transformation is that when a good modern project has only one “language” dependency, the application is easier to compile using Gnome technologies on platforms such as Windows. The transition from project to project also becomes easier.
One of the tools that undergo this transformation is GTK-doc , a tool for generating documentation, written mostly in Perl. I worked on converting it into Python 3 along with the team of creators. It was an instructive experience in many ways. First of all, it turned out that the conversion between any two languages usually falls into three phases:
- Manual syntax conversion
- Correction of bugs caused by conversion errors;
- Code conversion to idiomatic target language.
Converting Perl to Python in the case of GTK-doc is relatively simple. Work is conducted mainly with regular expressions, arrays and dictionaries. All these three types of entities behave almost equally in both languages, so the first phase for the most part boils down to purely mechanical work. The second consists of correcting all errors and behavioral changes made during the previous stage (many are caused by typing errors and inattention when performing the first step). In essence, this is a debugging phase. The third step is to convert regular expressions and global variables into objects and other normal and readable constructs.
In implementing the conversion, I was mainly engaged in the first step, and the developer, who led the project GTK-doc, agreed to complete the work on the second and third steps. In the process of converting 6000+ lines of the gtkdoc-mkdb file, I made some measurements, and it turned out that I can convert with a maximum speed of 500 lines per hour, that is, a line of code takes about 7 seconds. I achieved such results only if the code was simple to convert and all the work was reduced to training for typing speed in Emacs. Periodically, there were more intricate features of Perl, and on these fragments the pace of work slowed down by 10, 100, or even 1000 times. And if there were ports there that would need to change the architecture (this happens, for example, when converting from a more flexible language to one where the compiler checks the lifetime of the objects), they would take even more time.
I don’t know how time-consuming the second and third steps were, but if you recall some comments that flashed in the chat, I think it’s quite. According to the most optimistic calculations, the speed of work on these three types of elements was at an average speed of 250 lines of code per hour.
And now the saddest thing. With such speed it is impossible to carry out the conversion on an ongoing basis Manually translating code from one format to another is the most boring job imaginable; it is devastating and morally killing. I could not do it more than a few hours a day - at some point I started to ruffle in the eyes of dollar signs, semicolons and various brackets. Based on this, you can estimate that the conversion speed, which the developer can consistently maintain, working alone is about 100 lines per hour (I doubt that even this is real if the work on the project will last for several weeks, but there are no measurements, so we lower this consideration).
According to Ohloh, the cURL project consists of approximately 100,000 lines of code. If we assume that the conversion between any two languages is no more difficult than between simple Perl and Python (which is unlikely), then the whole process will take 1000 man-hours. That is, five months full-time work with an eight-hour working day. And when you're done, you have to transfer all the changes that were made during the conversion. Stopping work on a project while you are translating from one language to another is not an option.
From all this a clear and simple answer emerges to the question: “Why do people simply not translate the code into another language?”.
"Just rewrite language X" is impossible.
PS There are tools that convert from language to language automatically. They can help, but only in the first stage. The second and third stages remain on your conscience and may take longer because the manually converted code is clearer to people. The theory of completeness in Turing hints to us that everything is very bad.
Source: https://habr.com/ru/post/327070/
All Articles