The article entitled “On scripting languages and rockstar programmers”  discusses the merits and applicability of the use of scripting languages in large-scale programming projects. For the most part, I am in agreement with the author – for example, I agree that scripting languages tend to have a “shorter learning curve” in comparison to lower-level languages. I also believe that there are paradigms within scripting languages which could be tailored to fit the needs of large software projects by devoted developers. However, there are aspects of scripting languages which concern me when it comes to attempting to apply them to large-scale projects.
Firstly, in their overview of scripting languages, the author states that the majority of these languages are “dynamically typed.” Whilst I can see the advantages that this can afford developers – such as quicker implementation and more efficient code reuse – I feel that there are also a number of downsides that, based on the given project, could cause problems.
Due to their being no limitations on which “types” a function can accept at compile time in scripting languages, programs can be susceptible to attacks by hackers – for example, a piece of carefully-crafted malicious code – which would have been detected at compile-time – slipping past the interpreter at run-time . This can therefore make the use of scripting languages infeasible for security-critical systems such as banking software or systems which control access to confidential data.
I also believe that the use of scripting languages incorporating dynamic typing breeds laziness in developers to a certain degree. I of course can see that it can be more straightforward and faster to develop software using this form of typing, but I feel that it can inadvertently lead to software developers becoming careless and complacent over time, and – if working exclusively with scripting languages for a period of time – make mistakes more likely when using languages that require strict types for functions. While this may seem a very minor issue, it could still lead to hiccups in the development process.
The author of the article, when questioning the possibility of using scripting languages in large-scale projects, comes to the arguably-correct conclusion of “it depends.” They have acknowledged that for time and safety-critical applications such as nuclear reactor control systems, scripting languages can be too slow – mainly due to the fact that these languages tend to interpreted at runtime as opposed to being compiled beforehand. However, the author has left the door open for the discussion of less-than-critical scientific programs and their applicability in using scripting languages. One aspect of scripting languages which I feel can be improved in order to make them more applicable to a wider range of projects is to manually control garbage collection. A common occurrence in scripting languages is slowdown in performance whenever garbage collection is taking place: although this slowdown is usually only limited to a number of milliseconds, this can still have a negative impact upon some applications. By investing time in manually creating a more efficient garbage collector within a scripting language, the use of these languages can be extended to more scientific purposes where code is required to run optimally .
The author acknowledges the fact that, in general, low-level languages are more difficult to work with, and present a steeper learning curve for new users. Although they do take time to master, they can give the developer far more power and freedom to exert more control over their projects than any scripting language. My point here is, although the author acknowledges the fact that these are difficult languages to use, they should not simply be discounted solely for this reason alone. The advantages they may offer could possibly far outweigh the costs of taking the time to utilise them to their full potential. As with any language, once you have overcome the initial learning stage, the hard work is done and you simply need to practise occasionally to keep your knowledge intact: learning the language initially may prove time-consuming, but the knowledge gained can then be re-used on later projects. So, whilst there may be a quicker alternative to low-level languages in the short-term, greater benefits may lie ahead in future projects.
In the original article, the author made a number of good points in support of the use of scripting languages in large-scale software development, and outlined some of the benefits that these languages can afford over traditional, low-level languages. To a large extent, I am in agreement with the author: scripting languages are more easily-accessible for new developers, and can be used to develop solutions to non-critical software quickly. There are also methods by which these languages can be tailored to meet the needs of a client. However, there are some issues which are often overlooked – such as security of software in using such languages – that could prove damaging for software, especially in confidential environments. Ultimately, in deciding upon whether or not the use of scripting languages within a large-scale software development project is suitable, it all comes back to the author’s original conclusion: “it depends.”
 On scripting languages and rockstar programmers, s1038803.
 Dynamically typed languages, Laurence Tratt, Advances in Computers, vol. 77, pages 149-184, July 2009
 Herbert Schildt, 2004. The Art of C++, page 9. 1st Edition. McGraw-Hill Osborne Media.