Looking around the horizon of the web server side, I see that scripted languages like PHP are quite popular,
probably due to the speed of development and ease of programming. However scripted languages are human readable so isn't code security would be an issue here.
I would like to know that if I am keen of security of my code on the server what server language/technology would be most suitable.
the language has a small part to do with it. however, a lot has to do with how you actually design and write the code.
When you use any server side language, only people with access to the FTP protocol (or SSH), can see the files. When you are regularly browsing the web, you cannot see PHP, or any other scripting language.
In terms of the actual language security, little bugs can be found, but you will get that in every language. The security of your script depends on how you design it.
For the most part, every language is secure, but not every programmer is.
ASP.NET get compiled into dll's, so the code is not human readable on the server. But even in PHP, the code gets executed on the server.
Just stay away from JavaScript as that is visible on the client, and human readable.
My main preference is .NET, however even with the scripting languages like PHP they are not seeing your raw code unless you're giving people access to read the raw code files. I've seen some very secure PHP sites. If you're concerned about what people can see and access, then you need to watch what you are putting into the client side scripting languages like Javascript.
All serious (ignoring Piet, Malbolge, etc) programming languages are human-readable. Whether or not an explicit compilation step is required has no effect whatsoever on application security.
If you want to be very careful about security, use a language which supports easy verification and/or proofs, such as Haskell or Ada. A typical web application probably would be OK with a modern dynamic language, such as Python or Ruby. Java and C# are also popular, for performance reasons. Any of these will make developing secure applications significantly easier than in legacy platforms such as PHP, Perl/CGI, or classic ASP.
Lastly, as a small pet peeve -- PHP, Python, Ruby, Perl, etc, are not scripting languages.
scripted languages are human readable so isn't code security would be an issue here.
No, users on the web will never see the code of your serverside programms - unless you publish the source.
Some security problems in web applications stem from the type of language used on the server side: buffer overflow is a security problem typical of C. So a scripting language would actually be more secure in this regard.
Typical security problems in web apps today stem from the interaction of client, server, database and user-entered data:
A modern Web Framework like Ruby on Rails (or many others) will help you avoid some of these problems. But you still will have to learn a lot about web security!
"Staying away from Javascript" is a bit like "staying away from cars" because they are dangerous. Javascript is an integral part of modern web applications.
For 'hiding' the code there are a few different languages that support this. .NET languages can be compiled, which generates DLLs without containing the original source code on the server. These, however, can be read with something like .NET Reflector, so to escape that you would run something like Dotfuscator on your code, making it more difficult to read.
For PHP, there are solutions such as ionCube that encode your script and they must be ran with an additional decoder on the server to execute them. Usually this is used when reselling scripts, so clients can't look at or modify the source.
I would say that the only really safe way to protect your code is by using ISAPI or CGI, and developing the application with some hard compiled language like C, C++, VB 5 or higher but any .NET, Delphi 5 or higher and so on. Any bytecode or interpretated language can be decompied, no matter what you do. New obfuscation methods may hold the crackers for a while, but they will always find a way to get the source. The source is there, the decompilation routine is there, the source must be revealed to be used by the framework, so all the crackers have to do is to catch it on the way.