lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 23/10/2012 06:07, 乙振斐 wrote:

Without static type checking, we may send wrong parameters to a function
and we cannot find this mistake until the program crashes in run time.
But if it is a huge program, we are not able to cover 100% codes in test,
in this situation ,how can we prevent this problem?(say, pass wrong type
parameters to a function)

Sorry, I am a new comer with Lua, and it is the first time for me to learn
a dynamic language, forgive me if this problem is ridiculous. But it really
bothered me for a long time.
First, this is a relevant question, in fact one often discussed in programming circles. There is certainly no good answer, even less a solution. Maybe 3 points can be helpful (from my personal experience in both dynamic and static languages), or not: 

1. fields of errors
There are several kinds or fields of errors which i classify as:
* Programming errors, which prevent a program to work, either at "decoding" time by the machine, the language implementation (also in dynamic language), or at runtime when the wrong piece of code is executed. * Logical errors, meaning the program is correct but does not express what you actually mean, or should mean. For instance, a sort function that does not sort properly. 
* Conceptual errors, where your conception of what the program should mean is wrong.
Type errors are a subtype of programming errors. The difference with them in dynamic languages is that they happen at runtime. But they do happen, most often, because if a pice of data is of the wrong type, commonly any later operation with it will fail. The issue is partly that a bit of time is lost (you get the error later), partly that it is met only if the code path is run, and more problematically that it may happen at a distant place in code (and in your mind) from the actual source of the issue. Thus, we may have to think hard; this is for me the true problem with type errors in dynamic languages. However, type errors are not at all the most difficult ones in general, not the ones that eat our time, and probably not even the most common ones. Typically we (I mean, I) spend most of our time with logical and conceptual errors --the kind prevailing depending on the size of the project and previous knowledge in the domain. 

2. way of thinking
I noticed the following: after programming for a long time only in dynamic languages, when I then switch to static typing, for a while I have about no type error (at compile-time, indeed); then they start to happen, and finally I have many. I think, maybe, after some time we start "programming-thinking" differently. Dynamic programmers may have a clearer awareness about types --that is, ultimately, the meaning of symbols-- and unconsciously pay more attention to their coherence in the model. Conversely, after some time, static programmers may start to rely on the machine to do this job; and it does it well, provided your typing is correct and clear. They become so-to-say lazy about that, not uselessly spending their "neuronic power" in what a machine can do (better). 
Both are good, in my opinion.

3. trade-off
Finally, there is a trade-off of flexibility (and simplicity, and conciseness) versus security (and comfort, and laziness). Both are good, again. Unfortunately, we cannot yet have both... I guess it's not a question of technology, and in particular optional static-typing is not the right future of programming. Rather, there may be something basically wrong in our way of thinking about programming. (Maybe what we need is a kind of semantic types, embedding meaning in symbols, but I don't know exactly what this should mean... ;-). 

Denis