Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 539
  • Last Modified:

CGI or ASP?

I need to design some password protected form, which will communicate with database, find/present/save data, make some calculations, present data dynamically, etc.... What would be more suitable for this task - CGI (using Perl) or ASP? Genarally speaking, I also would like to know, what are the differences between Perl and ASP; what are their advantages/disadvantages, etc...
0
henefeld
Asked:
henefeld
  • 4
  • 4
  • 2
1 Solution
 
JerfCommented:
My experiences with CGI-programming and databases have been extrememly positive when using ASP.
I found the Perl DBI libraries very lacking and didn't hold a candle in comparison to ASP.
I would never deal with files in ASP, however, or do any tricky regular expressions (ASP's regular expressions are terrible.)
Another consideration is what kind of web server are you running?  If it's IIS (Microsoft) I'd definitly lean towards ASP over Perl...For ASP it's a simple matter of setting up a database through ODBC, hooking your Database up and dishing out information.  Perl needs the correct libraries installed (they usualy are) and a bit trickier code.
If, however, you're dealing with an Apache server (of any kind) then I'd go with Perl.  Perl and Apache have grown up together and they work very well with one another.
Both scripting languages have the same amount of development time but, if you've never dealt with Perl before, I would definitly go with ASP.  You can use VBScript or Javascript with ASP and they both have reasonably shallow learning curves.
Perl on the other hand...I've been working with it for a few years now and I still havent learned all its tricks :)
Both Perl and ASP have their uses, but their uses differ enough that they don't overlap as much as you might think.

0
 
henefeldAuthor Commented:
OK, first of all, thanks, it was very interesting.

Now, in the last sentance you say that Perl and ASP don't overlap too much. That's exactly the thing I need to know: what can you do with Perl, that you can't with ASP, and v. versa. I was pretty much under impression that everything you can do with Perl, you can eventually achieve with ASP.

My boss pushes me towards ASP, claiming that Microsoft always wins eventually; and the tendention to use Microsoft servers is growing. Personally, I like the power of Perl, and don't enjoy VB at all.

I didn't find any serious article on the Internet, comparing ASP and CGI (perl). If you know any, please, let me know.

Thanks in advance.
0
 
jhurstCommented:
I can only advise AGAINST ASP - I have written some relatively large applications using various data-bases and providing web interfaces.  My objection to APS is that you are tyoing yourself to one, non-open-license, vendor.  To me this is a BIG MISTAKE.

As to getting the job done.  I think there is little difference.  As to maintaining it in the future and having flexibility then ASP is NOT a good choice.
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
JerfCommented:
I really should have said that ASP and Perl will do the same thing, the real differences are under the hood.
I've had some bad luck with the Perl DBI and I'd really reccommend ASP for any database work.  There are alot of problems with the Perl DBI (such as calling the entire record set into memory, instead of just a section of it like ASP does).
Perl OTOH is much much much better at handling strings and doing regular expressions.  If you're planning n doing much string work, then I'd seriously look at Perl, but if, as you said, are just using your app to access a database and spit out the results, ASP is the easiest and more maintainable for this sort of work.
I've really never not been able to do something in ASP that I couldn't do in Perl and vice versa.  They're comperable languages in that they'll do the same things.  Some things are just easier and more developed in one language than the other.
Let me know if you have any other questions.
0
 
jhurstCommented:
I largely agree with jerf in terms of features.  I especially agree with his fear of tring to pull in the whole data-base.  If it gets big this is not a good idea in any language.  This is why perl has the each() and the various other ways of getting things without getting them all.  But his warning is legitimate.  I have seen people test data-base apps on small data-sets, then the world falls about when the data-set grows and the data-base will no longer fit in memory.  This is not a language problem though, this is just bad code and can be done badly in any language.

0
 
henefeldAuthor Commented:
Thanks guys. It was very enlightening.

I understand the problem with DBI.

On the other hand, I've heard, is that Perl would be a better option for savvy DB, like Oracle, etc...

What about PerlScript? Would it be something in between? I heard that one can embed it just like VB Script. Would PerlScript be a better choice? Or the DBI strikes again?

0
 
JerfCommented:
PerlScript is just another language that ASP can use to execute the server side code, like Javascript or VBScript.  PerlScript *is* Perl, only imbedded in an ASP.
ASP is kinda handy because you can use many different languages with it.
The only time I've ever used PerlScript was to write a specific function that parsed a string and returned an array.
Use the language for it's strengths.
0
 
henefeldAuthor Commented:
Perl is kinda handy too, I understand. You can use C programs with it.
0
 
JerfCommented:
Yep - I've never done it tho, but you can embed perl into C and vice versa.  Handy if you don't want to give away your source code.
0
 
henefeldAuthor Commented:
I accept the answer. Thanks, guys. Jerf was a little more helpful.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 4
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now