Episode 4: Scripting Languages

I’m surprised that Tcl was not mentioned in the list of scripting languages in use today. I was also surprised that the *extensibility* of scripting languages was not mentioned to make scripting viable for embedded systems development. One could extend (in pure C) cpu intensive portions of an embedded application, developed in Tcl for example. The topic of embedding a scripting engine into a conventional embedded-system/desktop/enterprise application was not discussed either. Tcl was designed from the ground up to be extensible and embeddable. It should not be surprising to note that besides other major projects, Tcl is used as a configuration-shell layer in Cisco routers. The future belongs more and more to high-level abstraction languages that allow extensibility/mutability. Tcl fits the bill in this regard.

This is an episode about about what is not true about scripting languages. The person being interviewed was so biased toward them, that they were almost not willing to admit that anything is true about them, probably because the things that are true about them are mostly negative things, so someone biased toward liking scripting languages would naturally have a hard time finding anything to say about them. Well, if your not going to say anything about them, then stop talking about them.

The definition of a scripting language is simple, it is a language designed to write scripts in. A script is something you run without having to compile it first. It might get compiled at some point, but that is not a manual step in process for running it. Scripting languages make it possible to take advantage of scripting environments, which make it easy to run scripts. In that sense, scripting languages are focused on being easy to run at the expense of everything else.

The fact that people have made compilers for some scripting languages does not change the definition or make it a bad one. It does not change the fact that these languages are not primarily designed to be compiled or take full advantage of being compiled.

They said there is nothing about them that necessarily makes them slower, but that is not true, and is an example of their bias. Scripting languages are slower, full stop. Their very nature makes this true. Take two languages that are designed almost exactly the same, except one is designed to be compiled as the first step toward running it, and the other is not. Which one will run faster? Obviously since these are two different languages we can’t say just yet. But being a scripting language does make that language slower than it would be if it were not a scripting language.

They also said there is not a really clear distinction between something being statically typed and not statically typed. Once again, their bias toward liking scripting languages is preventing them from seeing the truth. The truth is the exact opposite of that. The difference between statically and dynamic typing is very clear. I guess if they saw the difference clearly they would start to see how flawed scripting languages are for most professional programming, but they don’t want to see this.

Of course you can take the definition of just about anything and come up with situations where it doesn’t seem to fully apply. That is just the nature of language and speech. We never speak with complete clarity as that would require way too many words and thoughts. Human languages have a certain amount of vagueness to them because that is what makes them the most useful. A definition having a certain amount of ambiguity or edge cases where it does not seem to apply does not make it not a useful definition. Often that makes it more useful because if you were to include all the ins and outs in the definition, it would hard to see the underlying theme, and it would start to be difficult to distinguish it between the definitions of other things.

Static typing is better when it does not prevent an elegant solution and does not require lots of duplication. Dynamic typing can be better when that is not the case. Refactoring tools are the closet thing to proof that static typing is preferred. Even Uncle Bob, who is a huge proponent of TDD and high code coverage percentages, admits that you can be insanely productive in Java because of the InjelliJ IDE and all the refactoring it can do for you. As soon as you introduce dynamic typing you reduce how helpful tools can be because you reduce what they can know about the code.

Using scripting languages that primarily support dynamic typing to develop entire professional programs is usually stupid. People mistake easy to start running something with easy to get the project totally completed and working well. The person being interviewed admitted that he has a hard time recommending scripting languages to large teams. Well guess what? The same problems that affect large teams also affect small ones. What is a good or bad idea does not change with the size of the team in this case, what changes is how obvious it is that this is a good or bad idea. Let’s say using a scripting language it takes 6 months to get to a pretty good version 1.0. Let’s say it would have taken 3 months in a more compiled language. This will seem like not such a big deal because it is just an extra 3 months. It might not even be obvious that the scripting language slowed them down. But if you are working on a larger, more ambitious project which requires a larger team, problems like that are harder to ignore or miss. If it takes you 4 years to get to a good version 1.0, and using a compiled language would have reduced that to 2 years, it will be harder to ignore this or not realize it.