Hello everyone,
is anyone experienced with perl? Can it be run in XP or does one need a virtual machine? Thank you in advance. Thinlizzy
Perl for XP
Re: Perl for XP
Hi
There is an application that runs Perl scripts on Windows called ActiveState ActivePerl. It can be run without any need of a Virtual Machine. I have just added a tutorial for you on how to install perl under Windows XP.
If you want to run CGI scripts written in Perl under Apache, have a look at How to configure Apache server to run Perl CGI files.
Hope that helps!
There is an application that runs Perl scripts on Windows called ActiveState ActivePerl. It can be run without any need of a Virtual Machine. I have just added a tutorial for you on how to install perl under Windows XP.
If you want to run CGI scripts written in Perl under Apache, have a look at How to configure Apache server to run Perl CGI files.
Hope that helps!
Re: Perl for XP
You may find a very good Perl book named Modern Perl at https://robot.lk/viewtopic.php?f=90&t=2375
Thank You Very Much
Hello Neo and Kevin and everyone,
Thank you very much for helping me. I will try this very soon. Thank you also for the link about how to install Perl in an XP environment. Some months ago, I eventually loaded down a windows version from the official Perl homepage. However, I was then unable to run the interpreter. That was a pity. I just wanted to try it with some simple operations.
Meanwhile, I have borrowed a book on web programming in Perl. I will soon go into the matter more deeply and will also read the one you have recommended.
What has just occured to me is this: Whenever you program several devices - perhaps in a small autonomous network - then you write a Perl programme for real-time applications. However, the computers must be connected and use some protocols, needn't they?
Perl should have an interface for that, isn't that so? In the book for beginners, there was nothing said about this. I would like to know more about how the connection of various devices is really achieved in a Perl environment. Does the programmer have a say in which protocols to use? For example: Can she decide if she uses TCP or UDP as required with her application layer protocols? That, I imagine, should be possible. What else can she do? Can she change header values? Can she trace routers from Perl? The books I have read on Perl are not about such questions.
As far as I have heard, there are also alternatives to Perl that seem to be widespread, even though I ignore if they can be used in real-time. I assume it is possible, though. Many people seem to use an enhanced sort of C with Java routines for purposes particularly suited to the use of Perl. I would therefore like to know more about the prospective use of Perl. Will it still be used in the future, or has it already become a thing of the past? Why?
I would be grateful for opinions about this. If anyone has got information about this, will they please let me know, too?Thank you very much in advance.
Thinlizzy
Thank you very much for helping me. I will try this very soon. Thank you also for the link about how to install Perl in an XP environment. Some months ago, I eventually loaded down a windows version from the official Perl homepage. However, I was then unable to run the interpreter. That was a pity. I just wanted to try it with some simple operations.
Meanwhile, I have borrowed a book on web programming in Perl. I will soon go into the matter more deeply and will also read the one you have recommended.
What has just occured to me is this: Whenever you program several devices - perhaps in a small autonomous network - then you write a Perl programme for real-time applications. However, the computers must be connected and use some protocols, needn't they?
Perl should have an interface for that, isn't that so? In the book for beginners, there was nothing said about this. I would like to know more about how the connection of various devices is really achieved in a Perl environment. Does the programmer have a say in which protocols to use? For example: Can she decide if she uses TCP or UDP as required with her application layer protocols? That, I imagine, should be possible. What else can she do? Can she change header values? Can she trace routers from Perl? The books I have read on Perl are not about such questions.
As far as I have heard, there are also alternatives to Perl that seem to be widespread, even though I ignore if they can be used in real-time. I assume it is possible, though. Many people seem to use an enhanced sort of C with Java routines for purposes particularly suited to the use of Perl. I would therefore like to know more about the prospective use of Perl. Will it still be used in the future, or has it already become a thing of the past? Why?
I would be grateful for opinions about this. If anyone has got information about this, will they please let me know, too?Thank you very much in advance.
Thinlizzy
Re: Perl for XP
According to what I have understood, you need more control of the computer or device with the programming language you use. According to my expereince Perl will never match the real-time requirement and 100% control.
The best language that machines can read is it's native machine code. Since machine codes are hard to remember, we use a symbolic instruction code called Assembly Language. I'm sure you might have heard of this already. Since machine code change from CPU to CPU, Assembly Language changes as that. In other words, a program that you have written to work on an Atmel microcontroller will not run on a PIC microcontroller.
C++ answers this question. C is the most commonly used language for serious programming such as Operating Systems (Windows, Unix, Linux, Mac OS, Android, Symbian, etc... are written using C/C++), Utilities like Anti-Virus, Web Servers like Apache, languages like Java, Scripting languages like php, etc... C has the power to gain 100% control on all aspects of a device. Basically there is nothing you can't do with it. However in real-time, time critical applications, we use C and Assembly in a mixture. Most time critical parts are re-written using Assembly to gain maximum performance.
Languages like Java, Perl, etc... have limited features based on their libraries. So there is no guarantee that you get 100% control over the device. In the other hand, Perl is an interpreted language. You can't run it on a PC/Device without the interpreter. C is a compiled language. Whenever you compile you select the target as PC/Microcontroller/DSP, etc... and it compiled the most efficient code to that device.
So if you need control, efficiency, real-time, etc... on PCs or devices, C++ is what I recommend for you. In the embedded world, 90% we use C/C++. Only a few use Java that require more resources to run its JVM.
Also, if you know C/C++ 100%, it is an easy job to learn all other languages. The secret is almost all other languages are created using C/C++.
The best language that machines can read is it's native machine code. Since machine codes are hard to remember, we use a symbolic instruction code called Assembly Language. I'm sure you might have heard of this already. Since machine code change from CPU to CPU, Assembly Language changes as that. In other words, a program that you have written to work on an Atmel microcontroller will not run on a PIC microcontroller.
C++ answers this question. C is the most commonly used language for serious programming such as Operating Systems (Windows, Unix, Linux, Mac OS, Android, Symbian, etc... are written using C/C++), Utilities like Anti-Virus, Web Servers like Apache, languages like Java, Scripting languages like php, etc... C has the power to gain 100% control on all aspects of a device. Basically there is nothing you can't do with it. However in real-time, time critical applications, we use C and Assembly in a mixture. Most time critical parts are re-written using Assembly to gain maximum performance.
Languages like Java, Perl, etc... have limited features based on their libraries. So there is no guarantee that you get 100% control over the device. In the other hand, Perl is an interpreted language. You can't run it on a PC/Device without the interpreter. C is a compiled language. Whenever you compile you select the target as PC/Microcontroller/DSP, etc... and it compiled the most efficient code to that device.
So if you need control, efficiency, real-time, etc... on PCs or devices, C++ is what I recommend for you. In the embedded world, 90% we use C/C++. Only a few use Java that require more resources to run its JVM.
Also, if you know C/C++ 100%, it is an easy job to learn all other languages. The secret is almost all other languages are created using C/C++.
This was enlightening
Hello Neo,
Thank you very much. This was in what I have been most interested. It sounds like I could drop the whole Perl business altogether. It is part of the syllabus where I now study, though. I will not pursue the matter apart from that.
You have given many reasons why C is so well established and it sounds like it will remain like this. I thought Perl had special real-time capabilities but perhaps that is not so. Even if it were: C seems to have outperformed a couple of good programming languages, doesn't it? So, I will most likely try C.
Perhaps, you have saved me a lot of blood, sweat, and tears which would have been to no avail.
Thank you.
Thinlizzy
Thank you very much. This was in what I have been most interested. It sounds like I could drop the whole Perl business altogether. It is part of the syllabus where I now study, though. I will not pursue the matter apart from that.
You have given many reasons why C is so well established and it sounds like it will remain like this. I thought Perl had special real-time capabilities but perhaps that is not so. Even if it were: C seems to have outperformed a couple of good programming languages, doesn't it? So, I will most likely try C.
Perhaps, you have saved me a lot of blood, sweat, and tears which would have been to no avail.
Thank you.
Thinlizzy
Re: Perl for XP
You are welcome. Sharing knowledge is my passion. There are lots of resources for you in this website under C/C++ and embedded. We can discuss further issues/questions in detail next and I'm very happy to help.