|Written by Ian Elliot|
|Saturday, 09 November 2019|
It saddens me when people shoot off criticisms of languages they don't use and claim advantages for methodologies which are far from evidence- based. So imagine my disappointment when I encountered JS Johnny and an attempt to make static strong typing look good.
Of course, I'm not saying that static strong typing is bad - it's just a simple compile time check to try and ensure that an object has the properties you think it does. What most advocates of this sort of typing seem not to understand is that the compiler is mostly capable of working out these problems at compile time without the complexities of typing and it doesn't catch runtime problems at all. Yes indeed, we have all discovered that we are using the wrong type in a function call. I've even seen a beginner search out the correct object to pass by trying alternatives until the type checker stopped complaining! This reveals quite clearly that often strong typing is a stopgap for not writing documentation and not reading it.
I know that this is a very unpopular idea because strong typing has become the poster boy (thing?) for better programming for a long time now. What isn't well appreciated that there is very little evidence for this point of view. The few studies that there are suggest that if strong typing has any effect it is small and they don't consider any disadvantages. What is clear is that when you follow this particular approach a bit further you end up with a lot of "interesting" problems. After spending so much time enforcing strong typing you have to find ways of relaxing it so you can write type-free algorithms. The usual solution is to invent generics, something which Go is still struggling with it is so difficult. After generics you have to tackle variance and a range of other interesting problems, not to mention inheritance, interfaces and so on. All of these difficult and sophisticated concepts can be dispensed with if you just recognize that, like class-based inheritance, strong typing is easily replaced by other mechanisms.
As I said, this is not a popular point of view and I don't expect many programmers reading this to agree with me but even if you don't there is a case to be made in this instance.
The argument is that if JS Johnny writes a function:
then the poor sap has no way of ensuring that the function is called with a text object. The example given is:
Oh no, JS Johnny you have passed the entire WINDOW!!
As to passing a window to the function - well JS Johnny needs to read the manual and consider what parseText is doing. If it really is necessary to ensure that what is passed is a string object then test for it as the first line of the function. This protects against the error at runtime, which is much more important than the compile-time check of strong typing.
or email your comment to: email@example.com
|Last Updated ( Saturday, 09 November 2019 )|