 Syntax Checking the Scripting Way
started 4/30/2002; 9:30:50 AM - last post 5/3/2002; 8:32:52 PM
|
|
Ehud Lamm - Syntax Checking the Scripting Way 
4/30/2002; 9:30:50 AM (reads: 3015, responses: 14)
|
|
| Syntax Checking the Scripting Way |
|
(via Daily Python-URL)
A simple example hints at Pychecker's utility. Suppose you have written
the following fragment of Python source code:
status = 3
if some_rare_condition:
statuss = 15
log_result(status)
Is the issue clear? Often, when one encounters source resembling this,
there's been a mistake; the programmer intended status =
15.
Python accepts statuss as syntactically well formed, though.
This fact anguishes many developers who come to "scripting" languages
from C and Java, for example.
My recent Python adventures brought me exactly this anguish. My scripts would connect to the web server, get the web page over a slow link, only to die because of some silly spelling mistake.
I have always liked strongly and statically typed languages (with expressive type systems  ), but I have recently started to think that this was just bias. Now I am back to my old convictions (though for now, Python is my language of choice for scripting).
The reason I like tools like Pychecker is that one can imagine them providing varied kinds of analysis, ranging from 'spelling checks' to grammer checks and culminating in checks for proper use of idioms and so on.
Posted to Python by Ehud Lamm on 4/30/02; 9:44:23 AM
|
|
|
|
John Wiseman - Re: Syntax Checking the Scripting Way
4/30/2002; 11:08:53 AM (reads: 1571, responses: 1)
|
|
|
Of course, many mistakes can be caught even in a non-statically typed language. Most lisp compilers, for example, if given the equivalent of your python code would issue a warning either about a free reference to an undeclared variable or an unused variable.
I'm actually a little surprised at how infrequently I make a mistake that a statically typed language would have caught for me.
|
|
Ehud Lamm - Re: Syntax Checking the Scripting Way
4/30/2002; 12:26:16 PM (reads: 1619, responses: 0)
|
|
|
Since LtU tries to be a high quality weblog on programming languages, I really should be punished for mixing typing with static analysis (i.e., a compilation process). I am now going to stand in the corner for a bit..
|
|
Patrick Logan - Re: Syntax Checking the Scripting Way
4/30/2002; 11:44:56 PM (reads: 1512, responses: 4)
|
|
|
Whoever taught this programmer that it's OK to just write half the code (i.e. the app but not the test) should be flogged. I'll do it.
|
|
Ehud Lamm - Re: Syntax Checking the Scripting Way
5/1/2002; 12:12:06 AM (reads: 1585, responses: 3)
|
|
|
Patrick, I agree with everything you wrote, but I don't undrstand how unit tests (which I find essential) would have solved the problem.
I guess you are assuming that the problem surfaced after the program was released (this does make sense, otherwise why emphasize that the condition is rare). But suppose adequate testing is being done. Testing will take more time if this kind of error isn't caught by static analysis.
That's why I gave as an example a situation in which testing takes time because of using a slow net connection. Obviously, when working on something more substantive I would have worked on a local copy of the data. But this really isn't the important thing, you can assume that tests take time because the program is CPU bound, IO bound or whatever.
|
|
Ehud Lamm - Re: Syntax Checking the Scripting Way
5/1/2002; 12:25:11 AM (reads: 1653, responses: 2)
|
|
|
And then you think about compiling unit tests into static analysis code (i.e., design a notation to specify unit tests that allows static properties to be identified and checked before runtime). Sounds like a cool idea.
But hey, I know such a notation, it is called a type system
|
|
Noel Welsh - Re: Syntax Checking the Scripting Way
5/1/2002; 1:01:19 AM (reads: 1721, responses: 1)
|
|
|
> But hey, I know such a notation, it is called a type system
It's not that simple. For example, O'Caml's static type system won't test that you perform socket/bind/listen in the correct order. I know one could develop a type system that would test this, but hey, I've got programs to write so I'll still be using unit tests.
|
|
Ehud Lamm - Re: Syntax Checking the Scripting Way
5/1/2002; 2:05:07 AM (reads: 1774, responses: 0)
|
|
|
You are right, of course. We disucssed this issues many times in the past.
What I was suggesting is that parts of the unit tests can be analyzed statically. So I propsed the thought experiment: think of a languages that did exaclty that. Now what are these static properties? Some things that you yourself would find hard to check statically will get tossed away, the rest are going to be (I predict) things that expressive type systems give you. And by expressive I don not mean something that can only by found in some toy academic language.
But I agree that we still have a long way to go in program analysis and in the design of type systems.
|
|
pixel - Re: Syntax Checking the Scripting Way
5/1/2002; 2:57:56 AM (reads: 1486, responses: 0)
|
|
|
|
Dan Shappir - Re: Syntax Checking the Scripting Way
5/1/2002; 3:21:54 AM (reads: 1477, responses: 1)
|
|
|
I think its obvious that any check that can realistically be done statically should be, and that static type checking is better that the equivalent dynamic checking, i.e., unit tests. This is not to say that dynamic tests shouldn't be done (in fact, they must be done), it's just that you can (probably) never test for everything, and static test, with proper support by the language/compiler tend to be more rigorous. Specifically, I do not want to write unit test simply for the fear of having misspelled a variable name.
I do think that most programmers find it easier to code tests imperatively than by defining the appropriate type system. This may have to do with education, but that's the way it is. OTOH I do think most programmers are willing to pay the price of explicitly specifying variable type (variable declaration) plus a quick lint step.
Another solution is to use simple variable names like 'i' or 'x' ;-)
Or clean your keyboard so that the keys don't stick
|
|
pixel - Re: Syntax Checking the Scripting Way
5/1/2002; 3:30:50 AM (reads: 1466, responses: 0)
|
|
|
>Another solution is to use simple variable names like 'i' or 'x' ;-)
I don't think this is dumb. Scheme do have a convention associating names and
types (eg: equal? and set!)
more on this
|
|
Ehud Lamm - Re: Syntax Checking the Scripting Way
5/1/2002; 4:16:10 AM (reads: 1527, responses: 0)
|
|
|
I agree, with one reservation. Type systems should be simple enough for programmers to understand and reason about. I know this is a somewhat subjective criterion, but that's life. Designing useufl type systems is an engineering effort. You must decide on tradeoffs.
|
|
Patrick Logan - Re: Syntax Checking the Scripting Way
5/1/2002; 2:55:36 PM (reads: 1442, responses: 1)
|
|
|
Who could argue against a type system or any check that prevents errors earlier rather than later?
The only problems I have with type checkers are the restrictions they put on the language itself. Type checkers restrict what can be expressed in a language to just the language that can pass those checks.
Java-like languages (and I include C# and C++ for this discussion) are way too restrictive.
More modern type checkers, like those for Haskell and ML, are less restrictive and getting better all the time.
Hooray!
Meanwhile I find I am more productive in a fully dynamically type checked language like Scheme or Smalltalk *if* I write the unit tests that would have to write anyway.
The error described initially would have easily been caught had that code been associated with a test right from the start. There would have been no delay... no one but the programmer (or pair) that wrote the code would have ever seen this problem.
|
|
andrew cooke - Re: Syntax Checking the Scripting Way
5/3/2002; 7:56:39 AM (reads: 1459, responses: 0)
|
|
|
How do you write unit tests for code that is inserted into a larger system? I'm thinking of J2EE, where you effectively extend a Java based web server by writing Java classes. These classes function in the context of the server and it can be very difficult to test them standalone (it's often practically impossible, since many classes are accessed remotely - this allows the final application to be dispersed across a cluster of servers).
Maybe a more dynamic language would avoid some of the low-level details that make testing difficult? Has anyone here developed (say) a Lisp based distributed system? Is the remote access transparent? Is it easy to test? I am guessing that the Lisp equivalent of the J2EE server would have a much more open interface. Would you still need good documentation?
On a more practical level, does anyone have tips for testing J2EE (my current best hope is a student on work experience writing an intelligent web crawler to test the site)?
|
|
Patrick Logan - Re: Syntax Checking the Scripting Way
5/3/2002; 8:32:52 PM (reads: 1358, responses: 0)
|
|
|
Test a servlet by keeping the application logic separate from the servlet. Test the application classes using junit. When that works, wrap the servlet around it and test the system. If the application code works but the servlet breaks, at least you know where to look first.
|
|
|
|