Scripting Musings

Continuing my journey of learning regarding scripting languages (starting here):

I like it because it saves typing. There was a good example of a 20-line Java program that was reduced to 3 lines in Groovy. I’ve lost the link though. Posted by: Jonathan Aquino I like readability. Java can definitely be overly verbose at times, particularly with IO:

BufferedInputStream in = new BufferedInputStream(new InputStreamReader(System.in()); however, number of lines required to do something isn't something that I really consider when choosing a language. Obviously if it's at either extreme it matters, but few languages are either so short or so long that it really impacts readability. I'm also far more concerned with maintenance time than with development time because maintenance time almost always outweighs development time. Having said that, many people do like really compact languages and some scripting languages provide that (HyperTalk certainly doesn't). Greg Black adds some 

interesting comments as well. I certainly see the benefits of scripting for quick and dirty solutions or small programs as I tried to point out. Greg also quotes me as saying:

I don�t see why they should be considered the be all and end all solution that people seem to think they are. My statement is obviously incorrect. I should have said: I d'7;t see why the should be considered the be all and end all solution that some people seem to think they are. ‘7;s quite possible that ‘7;s a very small population of people that believe that but recently'7;ve run into an awful lot of people who seem to believe that and I was wondering why th'7;d feel that way. Greg also quoted me as saying:

I wouldn�t consider C an option unless performance was absolutely critical for server systems…‘7;m not certain how Greg took that statement but it does occur to me that it may have been ambiguous. What I meant to say was: For server systems, I woul'7;t consider C unless performance was absolutely critical. In other words, for desktop applications, particularly where security i'7;t critical (ie: runs with only user permissions and only accepts user input including the users files etc, or where the non-user input can be isolated into a small section of the program easily). If a program only operates with user permissions on user input, then there is no security vulnerability if that user can cause it to overrun and execute arbitrary code. For the small sections where remote input is taken using good overrun-safe libraries is generally sufficient to avoid problems. However for programs that constantly operate on untrusted data and run from trusted or untrusted but still important accounts (like the account a webserver runs under) the “cost” of a buffer overrun is much higher and there is more code that will be subject to malicious use. By and large I agree with Greg. Bad programs can and will be written in any language, good programmers can and do write good code in any language. My argument however is that all software has bugs so we should look for ways to reduce the impact of those bugs. Using a language that automatically checks the bounds of an array is a very good way to do that. The other thing that I have come to realize (as part of my process of becoming jaded and cynical) is that while you might (or might not) be a great programmer who does all the right things, inevitably not everyone on your team will be. Code audits are a great idea to help find any problems they introduce and to teach them the right way to do things but things slip through. Using a language that makes buffer overruns impossible is a major security benefit. It is not a stability benefit because the system will still crash but at least it w'7;t allow execution of arbitrary code. Also for the record, no I woul'7;t say I could code in C – I know enough to get myself into trouble but not enough to consider myself a C programmer by any means.