0

UPDATE: Received a lot of great info, thanks -- went back to read my question again, based on some of the answers stating that it's possible to do XYZ, which is not the question. the core of the question is this: "Main focus of this question is finding an answer in plain English of why Python, Perl, and Ruby are what they are when it comes to porting them to another language."

Been looking at the differences between Perl, Python, and Ruby -- and this to me has been one of the most interesting differences I've found so far, that being that it appears it's possible to transcribe Python into C, but it's not possible to transcribe Perl into any language. Haven't found anything about Ruby, but guessing that it's approach to 99.99% of everything is a object might make this hard if not impossible to do a transcription to another language.

Main focus of this question is finding an answer in plain English of why Python, Perl, and Ruby are what they are when it comes to porting them to another language.

Community
  • 1
  • 1
blunders
  • 3,619
  • 10
  • 43
  • 65
  • 2
    Here's a Perl->Python question on similar topic: http://stackoverflow.com/questions/3399781/why-is-it-not-possible-to-create-a-practical-perl-to-python-source-code-converter – P Shved Dec 12 '10 at 23:19
  • 7
    Your premise isn't correct. It is possible to convert all those languages in each other. It's just not practical. – kikito Dec 12 '10 at 23:24
  • @Pavel Shved: +1 Thanks, that was a huge help, almost even an answer to my question. – blunders Dec 12 '10 at 23:30
  • @egarcia: Yes, that's what I meant, my goal is not to transcribe a language, but to understand the differences at a very high level. – blunders Dec 12 '10 at 23:31
  • 7
    It is *possible* to translate Perl into C. – martineau Dec 13 '10 at 00:42
  • @martineau: Yes, you're correct -- though the point of my question is what this means in the context of comparing the languages. – blunders Dec 13 '10 at 01:02
  • @DownVoter: As a side note for whomever voted my question, down votes without comment do nothing to help the site, or the quality of content. – blunders Dec 13 '10 at 01:50
  • This is a pretty vague question, even with the update. – the Tin Man Dec 13 '10 at 01:54
  • @Greg: If I knew the answer, then I would not be asking. Already figured out a great deal based on the replies. These question was more of a fishing expedition; meaning that if one casts a wide enough net, your bound to score something, regardless of whether the resulting information was the goal of the question. In this case though, I did find an answer to my question; the first comment to my question. – blunders Dec 13 '10 at 02:05
  • 4
    @blunders "These question was more of a fishing expedition". Yes. Your question is *not a question*. Technically you're right, that's not a reason for a downvote. It's a reason for a *close*. – hobbs Dec 13 '10 at 02:06
  • @hobbs: "Your question is not a question." Really, how so? "Technically you're right, that's not a reason for a downvote." Are you reading the same text I am, don't think there was any correlation to my comment about the downvote, that is unless you where the one that downvoted the question and were reading into something that was not there; clearly you did downvote the question though, again without a clear reason -- since my question is a question, that has an answer. – blunders Dec 13 '10 at 02:23
  • 1
    @blunder "Clearly you did downvote the question though" no, I didn't, but thanks for the lies and insults! If you want me to downvote it now to prove that I haven't already, just ask and I'll be happy to! – hobbs Dec 13 '10 at 02:55
  • FWIW, I am only part of the way through reading this thread and its hilarious! I am going to think very hard and come up with a real whopper of an answer for it, I hope it isn't closed by then! – Joel Berger Dec 13 '10 at 03:39
  • @Joel: Cool, open to any input you've got -- thanks! – blunders Dec 13 '10 at 03:52
  • Ok so its closed, but here I go: Machines are made of replacable parts and thus for large enough machines (having enough parts) one could certainly build almost all others from the parts of any one. However lets work under the assumption that you want to use the machines as established to do the jobs of the other machines. I could certainly make an attempt to mow my lawn with a John Deere tractor, but it would be hard and suffer many problems. I could also use either my mower or the tractor to run in the Indy 500, but I would almost certainly lose – Joel Berger Dec 13 '10 at 04:02
  • each language is created with specific goals that work to accomplish tasks that the writers want to do. Lets look at a few languages that are very different. Perl very effectively operates on text. It does many other things well, but lets call that its thing. LaTeX, another fav language of mine typsets text. It is also turing complete, but let me tell you, do don't want to write a system script, parse a file or even write a do-loop if you can avoid it (though there are some extensions that help). Tcl is another scripting language that embeds itself into small systems. – Joel Berger Dec 13 '10 at 04:06
  • Lua is meant (as I understand it) to be run from other languages to other things that the language wants. Ruby is a successor to Perl etc and Perl was a successor to Awk (remember guys I am being incredibly general here). These languages are not supposed to be translated into each other. They are meant to be used to do the jobs that suit them. – Joel Berger Dec 13 '10 at 04:08
  • So now you have your fav language. Go ahead and use it to do that other job you need. Until you find that getting hard. Then embed the other language into the first one using something like Inline to do the meshing. Then when even that doesn't work, write a bash script around multiple languages doing multiple things. By now you have realized that you have a problem that needs real solving. So you write the language that you need to do your things well. Then someone can ask you how to port it into D and someone else can ask you why it doesn't look as nice a python. – Joel Berger Dec 13 '10 at 04:11
  • @Joel: Yes, I know -- though in this case, the function of a language, and it's implementation do not directly correlate. In the case of Perl, perl only being able to read Perl was something I was aware of, though until today, I didn't realize the impact this might have on automated audits of Perl code; which in turn might lead to bugs, readability issues, etc.; not saying this is the case, it's just my limited understanding. If this is the case, it's related to how Perl was implemented, not concept of Perl's logic. I expect a lot from any language, including English -- maybe too much... :-) – blunders Dec 13 '10 at 04:20
  • @Joel: Also, I might add that part of my interesting is just that, an interest in how languages of all types came to be, are used, and function within the groups that use them; and how language compete against one another. More I know about scripting languages the more I find them to be different from one another; difference is just that, it's not a strength or weakness unless applied to a given situation. Most people focus on mastering a language; I don't, though currently my main interest in data transformation frameworks; hence Perl, Python, Ruby, JavaScript, etc. Thanks for your input! – blunders Dec 13 '10 at 04:29
  • 2
    Nitpicky note to the "all three are Turing-complete and, therefore, any can be translated to the others" crowd: The question does not comment on whether they can be *translated* to C, but rather about whether they can be *transcribed* to C. Not the same thing. Transcription is a very mechanical, often word-for-word, process; translation requires interpretation and understanding of the source text to create an equivalent translated text. (Not that I have any idea whether OP intended to make this distinction, but I live with a translator, so...) – Dave Sherohman Dec 13 '10 at 11:40
  • @Dave Sherohman: True that. I'd say @Ignacio Vazquez-Abrams' answer (currently highest-voted) talks about transcription though. – Piskvor left the building Dec 13 '10 at 12:46
  • @Dave Sherohman: RE: "Transcription Vs. translation" you're 100% correct -- and in fact Sinan Ünür change my "transcription" tag to "translation"; my focus was on transcription, not translation, which by default is not mechanical. That said, no one seemed to get that, or my question in general, which is why one language may lend itself to transcription, and another may not. +1 for the clarification, which I didn't feel like covering, but likely should have. – blunders Dec 13 '10 at 18:40
  • @Piskvor: Not following you, as far as I'm able to tell, @Ignacio Vazquez-Abrams' answer makes no reference to transcription, but only to translation. – blunders Dec 13 '10 at 18:42

4 Answers4

10

It isn't that it's impossible to translate them, since any Turing-complete language can emulate any other Turing-complete language. The problem is generating an efficient translation, since some languages support features that are either very difficult or very complex to emulate in another.

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
7

Your question makes little —if any— sense, especially considering the questions you linked to.

Reading Why not translate Perl to C? might help you make sense of life, universe and everything.

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
  • @Sinan Ünür: My goal is not to translate Perl into C, although that has been a request from a client; that to me would be a different question. My goal is to get a high level understanding of what makes this possible in Python, but also why Perl's approach so different it's not possible; which is not a bad thing, just different. So, far Pavel Shved's link to this question has been the most helpful: http://stackoverflow.com/questions/3399781/why-is-it-not-possible-to-create-a-practical-perl-to-python-source-code-converter – blunders Dec 12 '10 at 23:29
  • 2
    The extent to which the question is pointless is independent of the scripting language in question. By, the way the point of the article "Why not translate Perl to C?" is not that it is not possible to translate Perl to C but that there is no reason why an ι of mental energy ought not to be wasted on the task. – Sinan Ünür Dec 12 '10 at 23:37
  • @Sinan Ünür: Funny thing is Sinan that your taking this is a weakness of Perl, and missing the point of this question -- which is what the difference are between Perl, Python and Ruby. Runtime has nothing to do with the point of the question. Feel free to harp on how bad the question is, your not doing Perl or it's community any favors. Instead you might focus on -- why -- this is special, and makes Perl a language to itself. – blunders Dec 13 '10 at 00:05
  • 1
    @blunders I am not taking anything as a weakness of Perl. The premise of your question is wrong. – Sinan Ünür Dec 13 '10 at 01:10
  • @hobbs: It's been done with Python, to my knowledge it has not with Perl. If one were to create a method to do this, this approach would be completely different. So, while saying that's it is possible may be true, it avoid the core of the question -- which is why Perl, Python, and Ruby are different. Difference is not a weakness, or a strength -- unless applied in context. – blunders Dec 13 '10 at 01:14
  • @Sinan Ünür: My understanding is that static analysis of Python code is possible, but in some cases with Perl it's not. If this is the case, how would Adam Kennedy’s PPI module, which attempts to parse Perl code without running it be able to enforce code policy if the nature of the meaning of the code is so abstract? (PPI is the backbone of Perl::Critic, which I'm sure you know. And the source of this is "Perl Is Undecidable", in The Perl Review, Volume 5, Issue 0, Fall 2008, pp. 7-11.) Seems to me that understanding this is pretty important in the context of using Perl, for better, or worse. – blunders Dec 13 '10 at 01:28
  • @blunders What, prey tell, does any of what you say in the comment has anything to do with translating Perl to C? You chose the words you chose in your question. If you meant to ask a different question, you should have asked a different question. True, only `perl` can parse Perl, but that is not what you asked about. See also http://www.jeffreykegler.com/Home/perl-and-undecidability – Sinan Ünür Dec 13 '10 at 01:57
  • @Sinan Ünür: RE: "What, prey tell, does any of what you say in the comment has anything to do with translating Perl to C?" -- From question, unedited: "Main focus of this question is finding an answer in plain English of why Python, Perl, and Ruby are what they are when it comes to porting them to another language." – blunders Dec 13 '10 at 02:09
  • @Sinan Ünür: "See also jeffreykegler.com/Home/perl-and-undecidability" -- Yes, that's were I got the "Perl Is Undecidable" -- so, seems to me that if it's true only perl can parse Perl, then "how" can a human parse it? (Especially those who did not write the code in the first place. Please do not read this as Perl is write only, just trying to understand the scope of Perl's abstractness; if in fact it is abstract.) – blunders Dec 13 '10 at 02:15
4

Any Turing-complete language can be translated into any other turing-complete language, it just takes a lot of effort and may look very ugly. Perl is special because its parser is full of special cases, but that does not make translating Perl to anything impossible, just very hard. Python has a pretty nice grammar and is easily parsed. Ruby has some peculiarities from Perl, but is still comparatively clean.

Think of it like this: Every language executes code on your CPU sooner or later. You can always take this machine code and "decompile" it into any higher level language, but depending on the code complexity, your results might just not be very useful for humans to understand.

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
moeffju
  • 4,363
  • 2
  • 23
  • 22
2

I understand what you asking, but that's not the right question (I'll get to that in a second).

Answer is because Perl is not defined by a formal language definition. Perl is somewhat in uncommon in that the reference for the language IS the implementation of the interpreter. Other languages such as Python, and C have a language definition. This definition is the reference and the compiler/interpreter is implemented to conform to that definition.

This reference allows someone to take the lexer/parser steps for one language and apply it in reverse to the syntax tree of another language.

ie. Python Lexer -> Python Parson -> AST -> C Parser -> C Lexer

This allows you it easily create a program to transcribe Python to C. Of course it's not that easy, but you get the idea.

For Perl there is no reference other than the Perl interpreter. Because there is a reference, it is possible to create a program that will translate the code, HOWEVER it would be very difficult compared to a language that had their reference in BNF (for example).

The question you wanted to ask is:

Why is it so much more difficult to automatically translate Perl to C and vice-versa, than Python to C?

dietbuddha
  • 8,556
  • 1
  • 30
  • 34
  • +1 That's the first I've heard that, thanks. So, is that really more the reason than the reasons listed here: http://stackoverflow.com/questions/3399781/why-is-it-not-possible-to-create-a-practical-perl-to-python-source-code-converter – blunders Dec 12 '10 at 23:50
  • Selecting you as the answer, since it lead to me finding the answer I was looking for, and addressed the question instead covering another subject. Cheers! – blunders Dec 16 '10 at 00:45