If you're trying to make a profit by selling your software, would you write your application for the OS that runs on (a) 90% of the computers out there, or (b) 4% of the computers out there (I'm making up the numbers)?
That entirely depends on the type of software. If you write something, and then have to resort to advertisment to convince people they really, really need it, you better go for the 90%. On the other hand, if you write software on demand, you have a small loyal customer base, or you write systems that'll run on dedicated servers anyway, marketshare of the OS matters a lot less.
If you are a very big company, and you are going to shell out $60 million for some custom software, marketshare of the OS it runs on will be a minor issue.
I can do lots and lots of useful things in C, pulling in just the [single] libc library.
0 != 1.
Now, try to do anything useful in Perl, without pulling in a memory hogging interpreter.
ls -l/opt/perl/bin/perl/lib/libc-2.1.2.so -rwxr-xr-x 1 root root 4087540 Nov 3 09:39/lib/libc-2.1.2.so -rwxr-xr-x 2 camel camel 1808363 Apr 8 1999/opt/perl/bin/perl
And, yes, you can turn your Perl into a tiny binary and use libperl as well.
Btw, ever seen the size of a hello world executable perlcc produces? ~500K on Linux/x86
You lucky devil. It's 1.8Mb on mine, and then it coredumps as well. But, who cares? One doesn't need perlcc to do lots of interesting things with Perl.
It's one of those "let's bash Perl again - cause it's too difficult for my little brain" threads again. Anyway, at0m asks: Perl seems to be the language that most people use for CGI programming. But is there a good reason for it? Sure, it's easier to use Perl than a lower level language, but programs would be more efficient if C/C++ were used.
Sure. All people using Perl are idiots, and would have been better off using C/C++. After all, CPU cycles is all that count, never mind I/O, network traffic, databases, the availability of modules, maintenance and development cost. They're all irrelevant. CPU cycles! CPU cycles! Close your eyes to everything else.
CPU cycles are cheap. A few weeks of saved programming costs can buy you a very nice and juicy machine. Perl develops a lot faster than C or C++. And many times, the CPU time of a CGI program is irrelevant anyway. Many programs are I/O or network bound. Who cares if your program runs in 30ms instead of 200ms if you have to wait half a seconds for each of your 20 database queries?
As for putting C++ in the same class as C when it comes to speed; please read Kernighan and Pikes book of earlier this year. In a comparison between various languages, the only language to beat Perl in speed was C. Perl was significantly faster than C++.
One thing that Perl has, and C doesn't, is buildin security. Not only is there taint mode, that doesn't allow you to use untrusted data to do something potentially dangerous, but when is the last time you heard of a security hole because of a buffer overflow in a Perl program? Unfortunally, examples of that happening in C are all too common.
In general, Perl isn't as fast as C. But in many cases, it's fast enough. And the other benefits Perl gives you, and C doesn't far outweight that.
Having said that, I'd be delighted if people stopped thinking "Perl!" when they hear CGI. Let some other community deal with all those luser programmers flooding c.l.p.misc and #perl.
The classic example in my mind is that you can have Perl take an action on a "default" variable. The statement chomp; drives me nuts. Sure it's convenient to not have to specify what you are chomping. But if you put enough of these kinds of statements in a row it quickly becomes hard to tell which variable is being acted upon.
Really? How many chomps do you need in your program that it no longer acts on $_?
If you were working with a bunch of people who's talents you did not trust what language would you pick?
That is an interesting question, but hard to give a single answer. It depends. On the size of the project, (amount of code, number of programmers), and how much can be invested in training.
Perl would not be my first choice - but for some projects, Perl might be good anyway. C wouldn't be an obvious choice either - unless the nature of the project more or less demands it. I'd look into Eiffel, Ada, Java and Python. And maybe even Lisp or ML. It all depends on the project, and people involved.
I really dislike the way Perl's OO works. But I am quite confused about the claim that Pythons OO system is better. Surely, you must know that Perl copied Pythons system?
One of the reasons I don't use Python is that it looks way too much like Perl - it doesn't give me anything I don't have in Perl. Certainly not in the OO part.
I think that perl sucks. I did a quick poll here at the office and the only people that like Perl are People that do NOT come from a 'traditional' programming background.
Care to tell us in which firm you work? I'd like to avoid ever ordering from a firm that has unfounded narrowmindness.
There are a lot of reasons not to like Perl. There are a lot of reasons not to like C. There are a lot of reasons not to like Lisp. Any language has lots of reasons not to like them - most reasons are quite subjective. I don't care if you like a language, or hate it. But if you are going around shouting "I think Perl suck", and don't give any reasons, then I think you suck.
Or perhaps you once tried Perl and it was too difficult for you.
perl is very easy to write, but it's difficult (for many) to read someone else's perl code.
Yeah, yeah, yeah, and NT is much more secure and stable than Linux.
Don't spread FUD. Code from bad programmers is hard to read - whether that's Perl, Python or C code. Code from good programmers isn't hard to read (unless they want to), provided you know the language. Don't expect to be able to read Perl code if you don't know the language; don't expect to understand C code if you don't know C either.
Perl isn't harder to read than any other language.
Bytecode is an implementation technique for interpreters. BTW, there is a real perl compiler in the latest release. It's just experimental.
Eh, what are you talking about? If you're so gung-ho by calling Perl "interpreted", then I wonder what you mean by a "real compiler".
The Perl compiler gives you C code. Which you can compile with a C compiler. Which gives you a huge binary, which basically is the same as you have after perl compiles the code.
Perl is "interpreted" about the same way compiled C code is - by a low-level interpreter.
The perl Interpreter reads line by line and compiles the code on the fly
Ah, the cluelessness of the average slashdotter strikes again. You have no fucking clue what you are talking about. Perl code gets compiled before it's executed. Just like C. The difference is, there's no separate compilation step. Perl compiles at several thousand lines/second, and the compilation step is usually hardly noticeble. With mod_perl, you even skip this, except the first time.
Spreading FUD about Perl is as useful as Microsoft spreading FUD about Linux.
It seems that to do anything useful in PERL these days I have to have 15 CPAN extensions
Ah, yes, if can't code your way out of a paper bag, and for everything you need to do you need someone elses work, you might need 15 CPAN modules.
I can do lots and lots of useful things, without having the need to pull in a single module. Now, try to do anything useful in C, without pulling in a single library.
josepha writes: and Linux is on its way to being a better UNIX variant than Solaris.
For which definition of better is that? One of the strong points of Solaris is that it scales very well. I can develop a product and compile a product on a Sparc 4, and have it run well on a 16, 32 or 64 processor Enterprise server. Scalability to more processors is one of the weak points of Linux.
You are of course free to have your opinions, but do you have any motivation to offer for those opinions?
Uhm, to me, that sounds like saying "eggs aren't fruit - they are white". "Regular expressions", in the traditional sense, describe regular languages. NP-completeness refers to a certain class of problems for which no "fast" solution is known. What I proved was that matching a regular expression against a string can be an NP-complete problem. And while the proof is based on the same property as why perl regexes aren't "regular" (the backreferencing), one doesn't follow from the other.
Up till 5.005, for instance, perl regexes couldn't match a balanced parenthesis string. However, the language consisting of balanced parenthesis strings, is recognized by a PDA. And it doesn't take super linear time to do the parsing.
Am I making any sense?
Abigail
Re:Better Balanced regexp, cool!
on
On Perl 5.6
·
· Score: 2
I find this really sad. Years, I've fought against this horrible naive idea that s/// would remove HTML tags. Even clueless Netscape programmers have left such naive parsing behind them years ago. s/// removes to much, and it removes to little, and only sometimes it happens to work out. There are decent parsing modules out there (well, they don't get it all right, but neither do browsers), the FAQ has been warning against s/// for years.
I don't believe any regex featurs are going to help you. If you use s///, you're just way to naive. You should step away from programming - go play quake or something like that.
Slashdot Mirror
That entirely depends on the type of software. If you write something, and then have to resort to advertisment to convince people they really, really need it, you better go for the 90%.
On the other hand, if you write software on demand, you have a small loyal customer base, or you write systems that'll run on dedicated servers anyway, marketshare of the OS matters a lot less.
If you are a very big company, and you are going to shell out $60 million for some custom software, marketshare of the OS it runs on will be a minor issue.
-- Abigail
0 != 1.
Now, try to do anything useful in Perl, without pulling in a memory hogging interpreter.
ls -l /opt/perl/bin/perl /lib/libc-2.1.2.so /lib/libc-2.1.2.so /opt/perl/bin/perl
-rwxr-xr-x 1 root root 4087540 Nov 3 09:39
-rwxr-xr-x 2 camel camel 1808363 Apr 8 1999
And, yes, you can turn your Perl into a tiny binary and use libperl as well.
Btw, ever seen the size of a hello world executable perlcc produces? ~500K on Linux/x86
You lucky devil. It's 1.8Mb on mine, and then it coredumps as well. But, who cares? One doesn't need perlcc to do lots of interesting things with Perl.
-- Abigail
I don't know. You tell me. If they are as good as Perl, then why aren't they used more? Or is there some secret Perl advertisement campaign going on?
No way there are some instances where speed of program is more important than speed of development.
There certainly are. I never denied that. Keyword is of course some.
I'd follow that argument I'd conclude that windows is better than linux - after all, everyone uses windows. Can't be that everyone is stupid, can it?
I'd say the majority of computer users is way better off with Windows than with Linux.
-- Abigail
Sure. All people using Perl are idiots, and would have been better off using C/C++. After all, CPU cycles is all that count, never mind I/O, network traffic, databases, the availability of modules, maintenance and development cost. They're all irrelevant. CPU cycles! CPU cycles! Close your eyes to everything else.
CPU cycles are cheap. A few weeks of saved programming costs can buy you a very nice and juicy machine. Perl develops a lot faster than C or C++. And many times, the CPU time of a CGI program is irrelevant anyway. Many programs are I/O or network bound. Who cares if your program runs in 30ms instead of 200ms if you have to wait half a seconds for each of your 20 database queries?
As for putting C++ in the same class as C when it comes to speed; please read Kernighan and Pikes book of earlier this year. In a comparison between various languages, the only language to beat Perl in speed was C. Perl was significantly faster than C++.
One thing that Perl has, and C doesn't, is buildin security. Not only is there taint mode, that doesn't allow you to use untrusted data to do something potentially dangerous, but when is the last time you heard of a security hole because of a buffer overflow in a Perl program? Unfortunally, examples of that happening in C are all too common.
In general, Perl isn't as fast as C. But in many cases, it's fast enough. And the other benefits Perl gives you, and C doesn't far outweight that.
Having said that, I'd be delighted if people stopped thinking "Perl!" when they hear CGI. Let some other community deal with all those luser programmers flooding c.l.p.misc and #perl.
-- Abigail
Really? How many chomps do you need in your program that it no longer acts on $_?
-- Abigail
Indeed, you are not a Perl guru. If you were, you would know that the performance "hit" isn't that bad at all.
-- Abigail
That is an interesting question, but hard to give a single answer. It depends. On the size of the project, (amount of code, number of programmers), and how much can be invested in training.
Perl would not be my first choice - but for some projects, Perl might be good anyway. C wouldn't be an obvious choice either - unless the nature of the project more or less demands it. I'd look into Eiffel, Ada, Java and Python. And maybe even Lisp or ML. It all depends on the project, and people involved.
-- Abigail
I really dislike the way Perl's OO works. But I am quite confused about the claim that Pythons OO system is better. Surely, you must know that Perl copied Pythons system?
One of the reasons I don't use Python is that it looks way too much like Perl - it doesn't give me anything I don't have in Perl. Certainly not in the OO part.
-- Abigail
Care to tell us in which firm you work? I'd like to avoid ever ordering from a firm that has unfounded narrowmindness.
There are a lot of reasons not to like Perl. There are a lot of reasons not to like C. There are a lot of reasons not to like Lisp. Any language has lots of reasons not to like them - most reasons are quite subjective. I don't care if you like a language, or hate it. But if you are going around shouting "I think Perl suck", and don't give any reasons, then I think you suck.
Or perhaps you once tried Perl and it was too difficult for you.
-- Abigail
Yeah, yeah, yeah, and NT is much more secure and stable than Linux.
Don't spread FUD. Code from bad programmers is hard to read - whether that's Perl, Python or C code. Code from good programmers isn't hard to read (unless they want to), provided you know the language. Don't expect to be able to read Perl code if you don't know the language; don't expect to understand C code if you don't know C either.
Perl isn't harder to read than any other language.
-- Abigail
BTW, there is a real perl compiler in the latest release. It's just experimental.
Eh, what are you talking about? If you're so gung-ho by calling Perl "interpreted", then I wonder what you mean by a "real compiler".
The Perl compiler gives you C code. Which you can compile with a C compiler. Which gives you a huge binary, which basically is the same as you have after perl compiles the code.
Perl is "interpreted" about the same way compiled C code is - by a low-level interpreter.
-- Abigail
Ah, the cluelessness of the average slashdotter strikes again. You have no fucking clue what you are talking about. Perl code gets compiled before it's executed. Just like C. The difference is, there's no separate compilation step. Perl compiles at several thousand lines/second, and the compilation step is usually hardly noticeble. With mod_perl, you even skip this, except the first time.
Spreading FUD about Perl is as useful as Microsoft spreading FUD about Linux.
-- Abigail
Ah, yes, if can't code your way out of a paper bag, and for everything you need to do you need someone elses work, you might need 15 CPAN modules.
I can do lots and lots of useful things, without having the need to pull in a single module. Now, try to do anything useful in C, without pulling in a single library.
-- Abigail
For which definition of better is that? One of the strong points of Solaris is that it scales very well. I can develop a product and compile a product on a Sparc 4, and have it run well on a 16, 32 or 64 processor Enterprise server. Scalability to more processors is one of the weak points of Linux.
You are of course free to have your opinions, but do you have any motivation to offer for those opinions?
Abigail
Up till 5.005, for instance, perl regexes couldn't match a balanced parenthesis string. However, the language consisting of balanced parenthesis strings, is recognized by a PDA. And it doesn't take super linear time to do the parsing.
Am I making any sense?
Abigail
I don't believe any regex featurs are going to help you. If you use s///, you're just way to naive. You should step away from programming - go play quake or something like that.
Abigail