We all love our scripting languages with its simplicity, elegant and beautiful syntax, and the ability to quickly hack together a solution. One of the common features of most scripting languages is being weakly typed. Meaning that we don’t have to declare the variable’s data type before we use it; to some developers this is a time saver and is one of the appeal of using these types of languages. But like with most things it has its pros and cons, and these are 5 things that you have to consider before using a weakly typed language.
- Using them in a team is risky. Unless you have some kind of coding standards to determine what kind of type this variable is being used for, there is always a risk of somebody trampling on each others variables thereby causing side-effects all over the system.
- Maintenance issues. Going back on an already completed system after some time to do maintenance work on bugs is a nightmare in any language. Weak typing exacerbates this situation because of the danger of lacking checks and balances on what a variable can handle.
- Tool support. While the current state of IDE’s for scripting languages are improving. There is still work to be done especially on code assists, because of the nature of weak typing, this only partially works on some IDE’s.
- Error catching. Scripting languages are almost always are interpreted at runtime, therefore most conversion errors are not caught since there is no compiler to catch this errors. Even if there is a compiler, type information are dynamically determined by the interpreter.
- Performance/Optimizations. Statically typed languages have the advantage of having been optimized by the compiler. While interpreted languages are always a little bit slower than their compiled counterparts, dynamic typing and dynamic type conversions will always cause a little overhead.
10 Comments
“Using them in a team is risky.”, “Maintenance issues.”
I think you need good, stringent coding guidelines for strongly-typed languages too. All organizations employing such languages do that. It’s just that, yes the chances of making a mistake in weakly typed languages are more. But, the ultimate gains in terms of reduced code size, developer productivity etc are huge. A lot of boiler-plate just gets out of the way. But yeah, you do need a more disciplined a approach here. I think a solid set of Unit tests helps a long way in achieving that. And again, writing them for these languages is, arguably easier as compared to strongly typed languages.
“Tool support.”, “Error catching.”
This is certainly improving what with IDEs like IntelliJ & NetBeans leading the way. With code-complete, integrated unit test creation, type-inference & other cool features, some of these issues can be satisfactorily handled.
I have seen enough projects/products written in Java/C# that rely on Reflection to do a lot of dynamic stuff. Where’s the type safety, code-completion, refactoring etc there? But, the gains are nonetheless there.
Also, in a lot activities like XML parsing, file I/O etc (lots of situations involve that), you really don’t need the heavy baggage of type safety, which only bloats the code and hides the true intent of the code.
“Performance/Optimizations.”
This again is an area where things are showing tremendous improvement. Especially with dynamic languages aimed at the JVM. You should check out some of the shootout benchmark results.
I think, yes strongly typed languages have their place but it’s just that weakly typed ones haven’t yet got the same passionate attention as the former. It just needs a different kind of attention. Companies like Google, Nokia & others are preferring languages like Python & Ruby over their strongly-typed counterparts for certain types of applications. There must be some real gain they’re getting here!
Just my 2 cents…
You are talking about two separate things as if they were one.
1. Dynamic typing. This is where variables don’t have types, they only hold a value, which has a tag identifying it. E.g., in Erlang the convention is for the first item of a tuple to identify its ‘type’.
2. (lack of) Explicit typing. Explicit typing is where a variable has a type annotation attached to it, e.g., Foo bar; in Java. You can have static typing (where variables, not values, have types) without having explicit typing. For example, in Haskell, let x = 5 in x*x - x certainly has a type (Integer) but there’s no sign of a type annotation.
The implications of dynamic typing are unrelated to the implications of lacking explicit typing. And to round off, “lacking explicit typing” was a pretty poor way I chose, of saying “type inference”.
Strong and weak typing are pretty useless terms because everyone means something different by them. For example, in Python literature, strongly typed means “x cannot be converted to y implicitly”, which seems quite arbitrary.
@Ricky
While you are right, this is a bit of nitpicking since it is very clear the article refers to dynamic and non explicit typing.
What about “duck” typing?
Clearly another bullshit from somebody who doesn’t get it. Even if you have a so called STRONG typed language. It really doesn’t eliminate maintenance issue. Maintenance is largely base on design and level of code complexity.
Using in a team is risky? WTF. Since when using anything in software world is not risky? We manage risk differently.
IDE support? Dude, where have you been? Look at Netbeans, InteliJ, etc.
This post is a whole lot of crap.
@Bug
Did I mention anything about eliminating maintenance issues when using a strongly typed language? Please reread the point again.
As for IDE support, have you tried PHP/Ruby/Python in Netbeans/Eclipse? There are still work to be done with regards to code assistance.
Hi Jan,
I am interested into why these things are the way they are. Could you provide some code examples to show why each of these points are bad? Sometimes just saying “maintenance issues” is not really enough. When does this happen and how do we avoid it?
@John Rockefeller
For both team usage and maintenance issues the one thing that can solve this is having a strict guidelines on coding standards and making sure that everybody follows it. Having strict guidelines allows a developer, who isn’t part of the original team, to come in and do maintenance work without tracing too much code to find out what this variable suppose to do. I’ve several experiences whereby knowing the return types and object types allowed me to easily understand the flow and design of the software.
Jesus, give this guy a break. If you’re not REAL nitpicky about the nomanclature used in the article this guy has a reasonable, though often repeated point. If some of you people got off your high-horses and stopped being so bloody elitest maybe they’d have a chance at getting laid!
Weak (or dynamic,..or loose,..you choose!) typing can be a bitch to work with. Anyone with a real degree of experience knows this to be true.
There ARE disadvantages to using a dynamically typed language (as are there to statically typed languages) and while i don’t agree with some of the points in Jan’s post he’s mostly there.
1. Coding standards SHOULD be in place an ANY team but in reality, they’re not. Especially teams of developers with little or no formal qualifications,..which is more commonplace than you’d think.
Where a language is dynamically typed you might want to consider using a flavour of hungarian notation ,..most of your runtime errors are going to exist in the implementation, not the structural code.
2. Null point. Maintenance is a pain either way!
3/4. Tooling has come on a long way but it IS still a pretty ropey in places and without a compiler you’ve no first line of defence. On a large project with many dependencies, that can be a total arse!
5. I have seen some progress on this front too but it’s still not enough . check out Mozilla’s latest shot at JITing JScript; it’s called TraceMonkey i think.
What have dynamic program-languages to do with cults like Scientology? A lot. Look at the comments and look at the comments in other blogs. The “Dylang”-crowd is like a bunch of religious worshippers. And they are a very small vocal minority compared to the silent majority who uses static program-languages for good reasons!
The problem with strong typing is that it never is strong enough. We have int/decimal/float/real/double, but we do not have meters vs feet.
All languages that are touted to have strong typing do not really support meters vs feet problem. Maybe C++ can do that with operator overloading, but no one does it.
And these are most common problems one deals with. Same problem with strings. Is this SQL escaped string? or [ht|x]ml escaped string? or url encoded? How about preventing concatenation of ISO8859-2 encoded string with CP1250 encoded string? Funnily enough, SQL supports collations out of the box, but most programming languages do not.
Once I see a strongly typed system then I will use it. Right now current ’strong typed’ improves very little over weak typed.
Kind regards