VBScript vs. Perl Web Development Time Comparisons?

An Anonymous Coward with thoughts of rapid CGI deployment, asks: "My manager has asked me for something that would show the differences in development time between ASP/VBScript and CGI/Perl. He is trying to gauge time schedules for web projects, but I don't have a clue as to where such information would be documented. I am familiar with both architectures and know the differences, but I think he's hoping for white papers of comparisons. Can anyone tell me where to look?"

Comments

your looking in the wrong place..

[Anonymous Coward]

my place of work did this a while ago.. we tested the deployment time of a medium size project.

We tested ASP/VB, Perl, PHP and Java.

we found the fastest to implement, and the one that successfuly did what we want, had the best stability and fastest processing was PHP4, with the zend optimizer (For extra speed).

The buety of php is its so flexible. We were able to have numerous programmers, each with hugely different techniques, using it. It can be either fully OO, or function based, or a mixture of the two. This allowed for massive cuts in implementation time.

Depends on the people and project

[KyleCordes]

At the risk of being so general as to be useless:

1) It matters a lot what technologies the developers are familiar with... if they've done a lot of VBScript, they will probably get the job done faster that way and vice versa.

2) The project size is also quite relevant. I'd be inclined to choose a VBScript / ASP-intensive for smaller projects, and choose a "heavier" approach (such as Servlets, XML-XSL, etc.) for larger projects. Depending on how you use it, Perl could go either way... certainly one can do write-only Perl, but there are also large, complex sites built this way. It generally takes less Perl than it would VBScript or Java to get the job done.

Re:Depends on the people and project

[Black Perl]

I agree that it depends on people and project.

I've been in two situations where we had two separate developers, a VB and a Perl developer, work on the exact same project in the interest of getting it done as quickly as possible. (Disclosure: I was the Perl developer :-)

Perl won, by a longshot. Both in time and in size. But I can't take complete credit. Thanks to CPAN, everything you've ever wanted to do has been made into a module. All you have to do is load the module, initiate some objects, call a few methods, and you're done! Not that I tell the VB developers that. :-)

ASP's inherent problem: kernel mode

[yabHuj]

AFAIK Microsoft ASPs run - as (part of) the IIS - in kernel mode. If you have a bug causing an online loop the only way to stop that is to stop and restart the whole IIS (or sometimes the whole WinNT system).

This will slow the development down quite a bit. Plus the ASP/IIS/COM+/ODBCsomething can surprisingly easy develop a nondeterministic behaviour which is hard to understand and even worse to reproduce (read: restore after severe server crash).

In contrast to this standalone CGI (programs, not necessarily scripts) does not heavily interweave with other components but uses (or: should use) clean interfaces that are easy to understand and maintain. In addition to this standaloneable CGIs can be tested without any web service. First do an ASCII version of what you want to achieve, test it locally (like QUERYTYPE=POST; echo "parameter=locally&defined=from&command=line" | ./yourcgibin) and after that you can wrap it into nice HTML.

Did I mention that I like independence?

Re:ASP's inherent problem: kernel mode

[lynnroth]

ASP Applications can run in 3 different protection modes. Low, Medium and High

Low - Runs in the IIS process. Good for speed, bad for crashes
Medium - This mode pools all the medium apps in the same process.
High - Runs in a seperate process. Slower, but you can crash it all day and it won't touch your IIS process.

Re:Depends how resourceful the developers are

[clifyt]

What a fucking troll. For the first time I read many reasons why I should go Perl instead of ASP and a dumb ass like you posts this shit.

VBS/ASP is pretty damn fast. I tried switching over to PHP a year back and I was amazed how fricken slowly things were...and its considered a staple anymore -- getting to the point where it is more used than Perl. I don't care much for most perl. I like code that I can read and not have to think about. This isn't saying that perl is bad or I'm just a suckyass programmer that can't figure this stuff out, its just that when you are working on projects that more than 1 person is working on and a lot of the times you aren't available to explain why something does what it does, I want everyone else to know immediately what the code does. When you are dealing with a team of non-programmers (psychometricists and language experts) this is immediately a good thing. I can't explain linenoise to someone :)

So what do I do? I program ASP. Once code is static and I no longer need to mess with it on a regular basis, I have one of my programmers do it up in C (or hell even let VB compile it which I wouldn't recommend if you are looking at longevity) and throw it in one of our DLLs.

On my IIS boxes, I run the Active State Perl as well. I have serveral apps that run in Perl and do a good job. I run UBB on my IIS box...granted it runs faster on my linux box, but I can't complain. When i was running UBB5, I hacked it to use ASP when possible and used a SQL database (instead of text files) and it was a bit faster than it was in just perl, but that could be because its running on a M$ product.

As for stupid and trivial modules - I have a free FTP DLL that I use on my end. If the above user is paying $750 he is an idiot. There are a lot of free components to ASP, and many inexpensive ones. The only ones I paid for are the Persits modules (ASP Upload - because it was far stabler than the free one and ASPUser as I could get to the system and do user management from a console). Of the free ones, I have FTP modules, I have standard Socket Modules (which I use to grab bits from a non-sql compliant database on the Mac), I have kick ass mail modules that I used to admin a mailing list as well as archive everything (err...I now use Mhonarc for that end of things).

This has nothing to do with being stupid. It has nothing to do with 1/5 of the time in Perl (because I'm sure I can code just as fast as a perl junkie on the M$ side).

In Perls defense, its a great language for a single user or a bunch of geeks that don't like to think in an english like language. Its very portable. I can run it on just about any platform and a lot of stuff is compiled for it. Its also reasonable fast (though any compiled lang will kick either ASP/Perls ass). But, if you are targetting anything on the M$ Platform (and there are many reasons to do this), you should seriously look at ASP/VBS as a serious possibility.

blah

clif

Re:Defending vb

[Black Perl]

We dropped Perl for VB half way through a new web internet project with on a microsoft server. Performance reasons were the real issue with too many spawned processes using perl.

You're not comparing apples with apples here. You're comparing CGI with persistent interpreter. You can write CGI apps with VB and they'd be just as slow as Perl. On the other hand, you can use a persistent perl interpreter (mod_perl for Apache or PerlEx for IIS) and achieve speeds at least as fast as a VB dll. (OK, perl enthusiasts, I know mod_perl has benchmarked faster, but not so much as to be statistically significant)

This site, among many other large sites, can handle all its traffic quickly because of mod_perl.

-bp

In a word . . . Perl

[Camel Pilot]

Perl has _much_ faster development cycle then VBscript/ASP and is a better overall development environment for web based applications for the following reasons.

1. CPAN - Hundreds of reusable software components such as CGI(cgi tools), Storeable(data marshalling), LWP(web client), Template(seperate logic from presentation), DBI(DB abstraction), etc.

2. Perl has higher level functionality builtin and is efficient at handling text. Ask your VBscript programmer to show you the equivalent code for these common operations:

String interpolation
$str = "The time is $time $timezone $date"

Pattern Matching
# Find and replace in strings
$illiad_book = s/Hector/Gates/g

# Remove duplicate words from input
$input_text = s/\b(\w+) \1\b/$1/gi ;

Array manipulations
# Sort an array in reverse numerically
@sort_reverse_lst = sort { $b $a } @lst ;

# Filter directory listing for text files
@dir_txt_lst = grep /\.txt/ @dir_lst ;

# Break up text into sentences
@sentences = split /\./ , $long_speach;

# reverse operation
$long_speach = join "." , @sentences ;

Symbolic references
$var = "temperature";
$$var = 72.1 ;

print "$var = $temperature"; # Prints temperature = 72.1

3. Perl is portable, even more so then Java. Apache or IIS; Win32 or palm.

4. Start off with cgi and if you need speed later port to mod_perl(Unix) or perlex(activestate win32).

5. Can be used to extend Apache via mod_perl.

There is more but that should be enough.

Mason = HTML + Perl

[dannyspanner]

I strongly suggest you look at Mason. It is a Perl equivalent of ASP or PHP. It also has several very useful tricks such as templating and caching. While it traditionally works with mod_perl under Apache, some people have got it to fly under CGI.

Apache::ASP

[fwc]

I code in Apache::ASP which is basically a port of ASP to Perl. You write the code much like ASP- Basically you use a tool like DreamWeaver to generate the html and you then intermingle Perl in it. DreamWeaver recognizes each chunk as ASP code and handles it accordingly.

I find it very quick to program in. But again I've literally written megabytes of Perl scripts over the last 2-3 years, and I don't particulary want to learn PHP. If I didn't know perl, I might be inclined to look at PHP.

---

Re:Apache::ASP

[fwc]

Have you really looked at Apache::ASP?

This is real perl. Not VBScript. I have it running on my FreeBSD box. I'm using standard Perl Modules, for which there is one for about anything under the sun.

As for code size, I can't really argue one way or another. Speaking as a perl programmer, I'm not sure how you can get much smaller code-wise than a lot of perl scripts. From what I could see PHP was just perl with a slightly different (weird) syntax.

I fully agree with you, however, "real" VBScript-based ASP sucks. And is difficult to write, and so on and so forth.

I'm just used to using perl to do everything under the sun, and if I can do my web pages in perl in a "php-like" fashion it's a good thing.

Re:Apache::ASP

[raju1kabir]

I find it very quick to program in. But again I've literally written megabytes of Perl scripts over the last 2-3 years, and I don't particulary want to learn PHP. If I didn't know perl, I might be inclined to look at PHP.

You might well find it worth your effort. The equivalent PHP code to duplicate the function of a typical ASP snippet is about half as long and twice as readable. Plus it runs faster, is completely cross-platform, you don't have to pay weird fly-by-night companies to buy buggy COM objects for every little basic core function, and the documentation is actually useful.

Javascript too...

[guinsu]

Remember that Javascript (well, JScript actually) can be used with ASP. And I find it much easier to develop in than VBScript.

It's what matters to your developers.

[mgkimsal2]

The whole thing is a toss up, in the end. What works for some doesn't work for others. What types of projects are you working on? If it's all reusable code you develop internally, a staff competent in one platform is more important than the outside factors.

I've seen people develop rudimentary things quickly in both languages, and I've seen complex apps take a long time in both. I've not seen people develop something significantly FASTER in one language vs. the other. If something's going to take 4 days to do, after analysis of the problem, it'll probably take roughly 4 days in either language - there's testing, debugging, etc. no matter what choice you make.

Perl has the obvious advantage of portability. At the end of the day, that may end up being the most important should you need to migrate platforms for some reason.

HTH