Poll: What server side scripting language should I learn?

[dude8604]

If I forget one, DON'T VOTE, but ask me to add it to the list and then vote.

Btw, I'm just going to use it for some dynamic content on my website (not sure what yet)

 

[RedRooster]

Cold Fusion is slow, CGI is constricting, and ASP is too mainstream. PHP is the only way to go.

 

[yoda291]

Here's my take on it. Feel free to counter or disagree since I will be the first to admit I don't know everything.

ASP is prolly gonna be phased out as it seems predominantly based off of IIS which is slowly, yet steadily being replaced by both MS pushing .NET and puttin less emphasis on other web technologies as well as the ground being gained in the web server market for apache, boa, tux, and tiny.

Perl is always good to know anyways, because at some point or another, you're gonna be on a unix system staring at a tcsh/ksh/bash/zsh prompt regardless of what you do it seems. Doing CGI after that is actually pretty trivial.

PHP is very cool and simple to learn and for simple tasks that don't require the external PHP libs, you'd be hard pressed to find anything faster.

I've never used ColdFusion...so I can't fairly comment on it.

You forgot one of my new favorites - JSP/Servlets - One of the fastest server side languages and, IMO, coolest...tho finding hosting and implementation is a learning curve.

and I think that .NET counts too....but I don't like .NET anyways.

My personal recommendation would be for either Perl/CGI or PHP to start. --then again, I may have to compete with you for a job someday...so I'm officially recommending .NET ;-)

 

[Descartes]

For the record, .NET is not a language in any sense. Also, .NET embodies more than just that which is "server side". You add ASP.NET to your list of choices, which is a constituent of .NET and can be coded using any of the many languages that target .NET (C#, VB.NET, JScript.NET, J#, C++.NET, Eiffel.NET, etc.).

So, my vote goes for ASP.NET.

 

[gopunk]

asp.net

descartes is right .net itself is not really any one thing

 

[dude8604]

Wouldn't asp.net be part of the ASP category? Isn't .net just a newer version?

 

[gopunk]

<< Wouldn't asp.net be part of the ASP category? Isn't .net just a newer version? >>



it's pretty damn different.

actually asp isn't really a language of it's own either... it's sort of like a wrapper for VBScript, or Jscript. ASP.NET supports over 25 languages

 

[dude8604]

what about ASP? Does asp support more than one language too?

Also, you don't need to buy software for asp like with coldfusion, do you?


One more question...I've seen some server side (at least I think that's what they were) scripts that were exe files. How does that work?

 

[gopunk]

<< what about ASP? Does asp support more than one language too?

Also, you don't need to buy software for asp like with coldfusion, do you?


One more question...I've seen some server side (at least I think that's what they were) scripts that were exe files. How does that work? >>




asp supports two: vbscript, jscript.

no, no software other than notepad and a server that'll run it.

exe files could have been anything... you just have to tell the server to recognize the .exe files as a script.

 

[Descartes]

<< asp supports two: vbscript, jscript. >>



To extend what he's said; ASP inherently supports vbscript and jscript, but you can just as easily download Perl(script) or PHP and use that. There are differences, so it's usually best to stick w/ vbscript/jscript.

 

[notfred]

how is CGI constricting? there's nothing that you can't do with CGI. In fact, I'd say CGI is more flexible that PHP, and possibly coldfusion (Although I've never used it.... it has a very specific market) If you need anything done in CGI you can write it in whatever language you want. If perl's too slow, use C, if that's too slow, use assembly language if you like. Perl is jsut used so much wiht CGI cause it's so easy to do so many things in it. And it's plenty fast enoguh for almost any task you can throw at it (as far as CGI is concerned).

#!/usr/bin/perl -w
use strict;
use CGI qw/:standard/;
print header;
print "<html><head><title>Perl owns you!</title></head>CGI</html>;"

 

[Descartes]

<< And it's plenty fast enoguh for almost any task you can throw at it (as far as CGI is concerned). >>



But, not really?

For smaller applications CGI is just fine. When you're having to deal w/ millions of hits, managing transactions between disparate resources, managing state in a load balanced webfarm, CGI won't do. It doesn't help that a process is created for *every* CGI request. That screams lack of scalability. It just won't do in an enterprise environment.

 

[yoda291]

<<

<< And it's plenty fast enoguh for almost any task you can throw at it (as far as CGI is concerned). >>



But, not really?

For smaller applications CGI is just fine. When you're having to deal w/ millions of hits, managing transactions between disparate resources, managing state in a load balanced webfarm, CGI won't do. It doesn't help that a process is created for *every* CGI request. That screams lack of scalability. It just won't do in an enterprise environment. >>



Wait a minute...doesn't apache create a new thread for all web requests too? I thought this was why things like tiny and tux were faster. Now I'm confused...

Also, goin on the whole .NET dealie... CGI isn't a language either, cuz you can make CGI calls from a servlet, or a C program, or a script. I still think PHP is the place to start followed by Perl.

 

[Ih8canada]

VBScript

 

[notfred]

<<

<< And it's plenty fast enoguh for almost any task you can throw at it (as far as CGI is concerned). >>



But, not really?

For smaller applications CGI is just fine. When you're having to deal w/ millions of hits, managing transactions between disparate resources, managing state in a load balanced webfarm, CGI won't do. It doesn't help that a process is created for *every* CGI request. That screams lack of scalability. It just won't do in an enterprise environment. >>



99% of websites don't get millions of hits (let alone millions of CGI requests) per day. And even if you had a site that was getting millions of hits per day, A good server shouldn't have any trouble serving up 1,000,000 cgi requests per day. I don't know how much less overhead ASP.NET has with just one process serving up vb scripts as opposed to runnngi the perl interpreter many times, but I can't really imagine it's THAT much, considering that these things all run in multitasking environmets, often with multiple processors. Sure, there are a few places where it's absolutely neccesary to be faster than CGI allows, but not many.

 

[Descartes]

<< 99% of websites don't get millions of hits (let alone millions of CGI requests) per day. And even if you had a site that was getting millions of hits per day, A good server shouldn't have any trouble serving up 1,000,000 cgi requests per day. I don't know how much less overhead ASP.NET has with just one process serving up vb scripts as opposed to runnngi the perl interpreter many times, but I can't really imagine it's THAT much, considering that these things all run in multitasking environmets, often with multiple processors. Sure, there are a few places where it's absolutely neccesary to be faster than CGI allows, but not many. >>



You're probably correct, most websites don't get millions of hits. I think the OP should have further qualified what his/her goals are. As an enterprise developer, a process per request is simply not acceptable from a scalability, and thus, performance standpoint. Spawning a new thread to handle a given request is certainly less expensive than creating a new process.

 

[Cattlegod]

need a "I don't know" option.

 

[yoda291]

<<
You're probably correct, most websites don't get millions of hits. I think the OP should have further qualified what his/her goals are. As an enterprise developer, a process per request is simply not acceptable from a scalability, and thus, performance standpoint. Spawning a new thread to handle a given request is certainly less expensive than creating a new process. >>



It's my understanding that most server side scripts will generate a new process regardless. Indeed, one of the big factors that comes into play when I code using a servlet is that it will NOT spawn new processes for a single sequence(it's very tight knit). I have seen CGI code that does not do it and I believe that asp.net can be written to not spawn a new process if you have control over thread and process controls. It's always occurred to me that the distinction between how it's handled system-side is what it's written in. Generally, C++ written implementations have control over themselves and JSPs are written in Java. So anything that becomes byte code seems to be contained. With anything that has to be interpreted, however, a new process seems logical.

Besides the question isn't what is the best thing for him to learn...it's what is the FIRST thing he should learn. This is why I voted PHP over JSP. Also, is managing IIS really as bad a nitemare as everyone seems to say it is with all the security patches and high loads? My experience is mostly *nix based.