Response Article to “On scripting languages and rockstar programmers” by s1038803

On boring languages and productive programmers

tl;dr Scripting languages are great for initial development but lack community buy-in (tool support, adoption, etc) in order to be suitable for large-scale projects, especially if those projects are performance critical (which is more commonly the case than you'd think).


This is a response article to On scripting languages and rockstar programmers by Jakov Smelkin.

Smelkin's main point is summarized in his article's first paragraph:

[It] is not only possible, but oftentimes faster and cheaper to create a medium to large scale project using one of high-level scripting languages as a core of the system.

Throughout the remainder of the article, Smelkin walks us through the line of reasoning leading to his conclusion, comparing and contrasting the non-scripting language C to the scripting language Python. Smelkin's argument can, in essence, be summarized as follows. Scripting languages are high-level, interpreted, dynamically typed and garbage collected. The author notes that these qualities imply a number of advantages, including the following:

  • New code can be developed faster (leaving more time to fix bugs and add features),
  • Scripting languages are easier to learn and use. New programmers can be brought up to speed faster and that average programmers can reach their full potential (however mediocre that may be) and
  • The hit in program run-time and memory consumption is often inconsequential (and there are workarounds when it does).

While Smelkin's conclusion is tautological due to its vagueness ("scripting languages are great except for when they aren't") I will attempt to deconstruct his argument and disagree with the particulars of his premises.

NB: Since I don't know much of C, I'll illustrate my points by comparing Java and Python, not C and Python like in the original article.

Development speed

Smelkin states that scripting languages are great for medium to large scale software projects because their combination of no compile-time and highly productive syntax offer short development times.

Scripting languages are fast to write. No compile times. Fewer characters needed in order to implement functionality (compare: print "hello world" to public class HelloWorld { public static void main(String[] args) {...). Fact.

However, Smelkin seems to forget that writing code is one of the activities on which the least amount of time is spent during the software life cycle of large scale projects – time spent on software maintenance is much higher [1]. The real question to ask, therefore, is whether scripting languages help us doing software maintenance.

From my experience, maintaining code written in a dynamically typed scripting language like Python is an absolute pain when compared to performing a similar maintenance in a boring static language like Java. To illustrate this point, let us focus on what is maybe the most common software maintenance task: refactoring.

There simply aren't the tools to perform refactoring safely in Python. Point in case: compare the rudimentary refactoring support given by the popular Rope library [2] to more sophisticated, context-aware refactoring tools provided by IDEs like Eclipse [3] or IntelliJ IDEA [4]. They don't even play in the same league. Note that this dearth of tool support is not necessarily caused by the fact that Java is a more popular language than Python (and therefore has a bigger market and higher incentives for tooling to be developed). The simple truth is that due to their dynamic nature, scripting languages are unlikely to be able to enjoy the same intelligent tools that statically typed languages do.

Using a scripting language improves feature development time. However, due to poorer tooling, software maintenance tasks (the bulk of the software life-cycle) are slower. This may result in a net loss in productivity.

Programmer skill

Smelkin furthermore states that scripting languages are a great choice for large scale projects because they are easy to learn, allowing new hires to be productive faster and average programmers to be better contributors.

While I agree with the point that scripting languages are often easy to learn superficially, I disagree with the point that this is enough in order to write good medium to large scale software. Often scripting languages require a good deal of due-diligence and good behavior from the programmer (e.g. resisting the temptation to mess with private variables in Python – which can be enforced by the compiler in a language like Java). On the other hand, static languages help novice programmers through superior tooling (e.g. static analysis, highlighting syntax errors and type errors on the fly) and due to the compiler's ability to enforce conventions and invariants.

Scripting languages are easy to pick up and to write "hello world". However, they are more difficult to master. If anything, the ability to write large scale applications in scripting languages is the mark of a competent programmer rather than a novice.

Also, why would I hire a new programmer and train him/her in Python if I can hire experienced Java developers who can hit the ground running at a dime a dozen?

Execution speed

Smelkin also states that the oft-stated performance hit incurred by using a scripting language over a compiled language is irrelevant except for specialized fields such as scientific computing, embedded systems and so forth. Smelkin argues that for most projects, performance is not critical.

I agree with the point that performance is not relevant for all types of software. However, I think that performance un-critical projects are a lot less common than Smelkin seems to imply with his statement.

For instance, the following quote taken from [5] implies that even web development, a traditional bastion of scripting languages (PHP, JavaScript, Python, etc), could be called a performance critical field:

Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%

Granted, as Smelkin states, performance can always be increased by using better data-structures and minimizing IO operations. However, given the extreme importance of performance in some fields (illustrated by the quote above), I argue that optimal data structures, minimal IO operations and a performant language are the norm for in a lot more software fields than Smelkin's argument implies.


Smelkin states that scripting languages are a good choice for medium to large scale performance un-critical projects because they are easy to learn and quick to write. I agree – as long as the projects will only have to be maintained minimally and are truly not performance critical… arguably a much more narrow niche than Smelkin's original post would have us believe.


[1] Glass, Robert L. "Frequently forgotten fundamental facts about software engineering." Software, IEEE 18.3 (2001): 112-111.

[2] zjes "Rope, a python refactoring library …"

[3] The Eclipse Foundation "Eclipse"

[4] JetBrains "IntelliJ IDEA 13"

[5] Hoff, Todd "Latency Is Everywhere And It Costs You Sales – How To Crush It" High Scalability blog (2009)