Perl Vs. C

Replies are listed 'Best First'.
RE: Perl Vs. C by lhoward (Vicar) on Oct 30, 2000 at 23:36 UTC
For your situation here are some of the reasons I'd use to push for perl. Perl has a well-defined DB interface layer, DBI. DBI is database indepandant so if you ever decide to switch to another DB, you can do it with almost no changes to your scripts. w/ apache, mod_perl and Apache::DBI you get cached DB handles, so your scripts aren't constantly disconnecting and reconnecting to the DB server (which can really hurt performance) w/ apache and mod_perl (and optionally Apache::Registry, depending on how you want to do things) your scripts can run inside the web server; this is much faster use no separate process has to be forked. Perl is generally better suited for CGI's because it has a well defined CGI variable parsing library. If you need to do some C stuff you can always use Inline to put C code inline in your Perl programs.	[reply]
Rapid Rate of Development by tedv (Pilgrim) on Oct 30, 2000 at 23:51 UTC
Having used perl for a large corporate project that most suits would want done in C, the single biggest reason to use perl is that it gives you a rapid rate of development. That doesn't just mean you get it up and running, "quick and dirty". It also means that you can fix bugs faster. 40% of our project bugs were located and fixed in under 4 hours. How's that for rapid response time? Once an engineer came to me and said, "Your program doesn't work for this special system architecture because you need to handle this special timing message." I asked her for the technical specifications for the message, creating a new object file defining the message object, and hooked in the message to system startup. This whole sequence took 20 minutes and her code worked immediately. If this had been done in C++, we would have had a minimum 1 hour just to recompile the system, not to mention how much harder the design would be (due to C++'s strict methodology). Because of how large corporations work, it turned out that my group's project was doing the same thing as another group's project, which was using C++ (and later Java). We had 2 people on our team while they had 5. They had been working for 2 1/2 years on the project (or about 12 man years) while we had only spent 1 1/2 years. And yet their project could only do what ours did 9 months ago. I once considered just rewriting their project using our base core. I estimated it would take 4 weeks to completely recreate everything so it used their special interface, but it just wasn't worth the time. Too many people depended on our project, and they always wanted more features. At least they were easy to add. -Ted	[reply]
RE: Perl Vs. C by Malkavian (Friar) on Oct 31, 2000 at 00:19 UTC
Rather than being mutually exclusive, C and Perl fit together nicely. As a starting point, writing a system in Perl is a good step. It works rather nicely as a rapid development language, due to it's easy syntax, and it's abstraction from the lower levels that are required for C (pointers, memory allocation etc). C, for dedicated purposes, is faster than Perl in a good many areas, but, unfortunately takes far longer to develop, and is more prone to errors and undefined behavour. A question you should ask yourself is: Do you actually require that extra speed that compiled C will be giving you? Is your program the bottleneck of data transfer rather than the database accesses? If it seems that the database will be the main use of system resources, then you won't get much more kick for using C as your glue over Perl, and it could easily be a lot less maintainable. A good way to start something such as this, is to design the initial system, and code in Perl. Treat this as the prototype, as any major changes in functionality can be easily made. Once you're happy that things run as they should, perhaps start profiling, to work out where your bottlenecks are. You then have the option to either optimise these in Perl, or, recode in inline C. If it seems to you then, that you absolutely require the extra boost, then you have a working, functional model that can be used for reference while coding a C application that is logically identical, but, hopefully faster. After programming in both C and Perl, I've found that nearly all the things that I'd previously have used C for, I now use Perl, and, in the instances I still do C coding, I usually use Perl as a prototyping language to ensure that I have the design correct. So, to sum: Perl advantages: Speed of development Good early stability Good prototyping language Easily maintainable A large base of existing libraries to use, which are already heavily optimised and debugged for a great many uses. Can use compiled C to replace Perl functions for extra speed where required. C advantages: Very fast. Lower memory footprint. Higher degree of control over low level functionality. Anyhow, hope this helps, among the rest of the advice, Malk	[reply]
RE: RE: Perl Vs. C by merlyn (Sage) on Oct 31, 2000 at 07:06 UTC
And Perl and C fit together even easier thanks to Inline! -- Randal L. Schwartz, Perl hacker	[reply]
RE: Perl Vs. C by vroom (His Eminence) on Oct 30, 2000 at 23:47 UTC
If your programmers are gonna roll their own C scripts for handling CGI don't let them. Perl already has a very nice CGI module which handles all of that. Perl takes care of all the memory allocation for you if you write the code in C and don't dynamically allocate memory you leave yourself open to segfaulting or worse buffer-overflow attacks. Also Perl's powerful built-in pattern matching gives you the tools you need to do data-validation. String processing in C is a nightmare unless you're using libraries which handle all of the nastiness. Perl gives you a language with a feature set which supports the things you need to do text-processing well. It also takes care of most of the niggly details you need to worry about when writing C code. C is great when you need speed, or low level access. Perl's pattern-matching is highly optimized and probably faster than anything someone would write in C without spending countless hours on optimization. Development time in Perl would be quicker if you have a decent Perl coder. You don't need low-level access you need good text-processing capabilities which is one of the things Perl excels at. vroom \| Tim Vroom \| vroom@cs.hope.edu	[reply]
RE: Perl Vs. C by cadfael (Friar) on Oct 31, 2000 at 00:03 UTC
For what it is worth, I took over primary programming responsibilities for a Sybase database about 8 years ago, and dealt with an existing C interface as well as some perl scripts. I found the perl MUCH easier to work with. We still use the C code, but it has become less important as time goes by. When I started, Sybase was at version 4.8, Perl at 4.x. With the addition of the DBI module, as well as the nice features that came in with 5.x, I have been able to retire a lot of home-grown code in favor of easily maintained, standardized code that has scaled extremely well over the past few years. Bottom Line -- for DBA tasks, web interfaces, parsing of text files, extraction of data, and nearly everything else do as a DBA -- Perl is the number one choice. ----- "Computeri non cogitant, ergo non sunt"	[reply]
RE: Perl Vs. C by Fastolfe (Vicar) on Oct 30, 2000 at 23:36 UTC
(What does this have to do with GUI programming?) It depends on what you're trying to do. If your stored procedures are going to be doing all of your validation, what is your (Perl\|C) part going to do? Just simple form handling and passing off the data to the database? I'm not going to go into a comprehensive "Perl v. C" document, since there are dozens of them out there that do a far more complete job than I could here. In this specific case, though, Perl offers a benefit of rapid development time, in that there are modules already in place to do both the CGI stuff and database stuff, so a script to glue those two together in the form of a simple form processor would be pretty easy to write. If this is going to be something that is going to be hit pretty hard by a large number of requests, or if you already have staff on hand better equipped to maintain something in C, that might be your best bet. Depending upon the complexity of your features, using the appropriate modules in Perl, you can write a script to do this task very fast with very few lines of code. I'm not familiar enough with C to know how much reusable libraries you can use to perform some of the lower level tasks (parsing the CGI stuff and interacting with the database).	[reply]
RE: RE: Perl Vs. C by Fastolfe (Vicar) on Oct 31, 2000 at 00:52 UTC
Whoa this is odd. Why did this show up as being from Anonymous Monk? I was logged in (just as I am now), yet this node isn't under my name.	[reply]
RE: Perl Vs. C by mitd (Curate) on Oct 31, 2000 at 11:21 UTC
Experience has taught this old fart coder never to enter into religious discussions... Oh what the hell. Quite often I hear the refrain, "Well this Perl thing is all well and good, but you're looking at a team of 'C' guys and gals here." So what to do? Force this bunch of K&R's to learn Perl using your BIG Slam E-Commerce Project as the test bed for for thier first scripts? Hmmm... Here are a few tips, because yes Perl is worth it. Hire or contract a hardcore Perl 'er (some of these higher life forms can be found hanging around here) to babysit the 'C' gang through eary potty training. Buy the books, Buy the Books... they can read them on the above potty. Last but not least, if budgets allow, send them to a company like Stonehedge for training and a fast track to Perl adolescence. mitd-Made in the Dark 'My favourite colour appears to be grey.'	[reply]
And he said "Let the young be fed on Milk and Bread" by frankus (Priest) on Oct 31, 2000 at 15:06 UTC
I think your statement might be more palatable if it didn't demean C programmers by comparing them to toddlers. C is an excellent grounding to learn Perl. (If you want to learn Perl, It's fun :) Perl Developers I've met, who began cutting code with Perl, are unaware of how friendly, forgiving and rapid Perl is. I have seen some coders baulk at the sight of other languages: "Waddaya mean arrays are fixed length?!" "I have to do all this declaration before I start?" "Everything has to be in classes" "I have to watch for buffer overflow?!" "What are Hashes called in this language?" ...and so on. I am not saying you're wrong, but your zeal and 'good-natured' mockery do little to promote Perl or PerlMonks. -- Brother Frankus.	[reply]
RE: And he said by mitd (Curate) on Oct 31, 2000 at 22:33 UTC
"I am not saying what you're wrong, but your zeal and 'good-natured' mockery do little to promote Perl or PerlMonks." 'Soccer Balls!' <humility value=off> I started coding PDP Assembler in 1972. I have written 100's of 1000's of lines of 'C' and never once have I ever injured my funny bone. I had my first good Perl pooh in 1991. My Pink Camel has water stains caused a potty mishap in 1995. <humility value=on> Frankly Frankus suggesting that 'C' guys and gals don't have a sense of humour is ludicrous when everybody knows the only people with no sense of humour are APL programmers.¹ ¹ It should be noted that there is some controversy concerning the sense of humour of APL programmers since the creators* of APL obviuosly had unusally large funny bones.* No programmers were actually injured during makinging of this node mitd-Made in the Dark 'My favourite colour appears to be grey.'	[reply]