Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
11/12/11 05:42
Read: 444 times
Sweden


 
#184676 - You can't
Responding to: Jan Waclawek's previous message
Jan Waclawek said:
Even in compiled languages I am able to write - and have written, on uncountable occasions - errors which revealed themselves only later.

If this bothers you, you should adopt the same technique as with any other language - test what you've written immediately after you've written it.

There are of course so many variants of the "interpreted language" paradigm, with various minor points for and against them in various settings. The world is just not black and white.

JW

Compiled languages prunes down the number of combinations of errors you need to test for in a way that doesn't happen for a truly interpreted language.

Real programs aren't written fully and then tested fully.

They are incremental pieces of work.

With a compiled language, you can focus on what to test based on what additions you have made.

With interpreted languages, you have a much harder time to figure out how the changes may break older, pre-tested code.

It is a well-known fact that functions can normally be subjected to full testing whenever they are modified. You can have a test harness that tests all if statements, all limits for all variables etc. When combinting 500 functions into a complete program, the combinatorial math tells us that we can not perform such a complete test. It could take billions of years.

So we have to settle for testing what is possible to test. And the compiler (or static analyzers like lint) will be part of that testing environment. And they will test huge amounts of combinations that you will not be able to test with the interpreted language.

The compiler might drop the number of needed tests from 2^20 to 2^10. But that means that it will catch a large number of errors that you just can not set up test cases to catch for the interpreted language. You wouldn't even have the thousand years it would take just to write the test cases.

Remember also that most interpreted languages have weak type handling. So they can have a string "15" and allow that to be multipled by 2 and end up with the result 30. Weak type checking sometimes helps. But sometimes, it makes the program create a result even when the code was wrong and we sent the wrong variable to the function. With weak type checking, you get into troubles like is "" same as NULL or the value zero? Is "15hello" the number 15 or invalid? Should "hello " + "world" concatenate two strings or be a failed attempt to add two numbers from text input boxes on a web form?

But there are many other things that can go wrong with an interpreted language. For example the upload of a PHP-based web application to a server accidentally make one of the source files not readable by the web server. The application can run fine for a long time, until a web visitor does something that requires this file to be included for parsing.

Interpreted languages that gets bad data from a text input and doesn't guard about it, could accidentally try to run the text input data as if it was code. A common example is SQL injection, where people enter text data that looks like the end of a text string, and then follows this with a semicolon and some dangerous SQL statement. The programmer thought he performed a single SQL query in the database, but his query ended early and after that followed a SQL statement requesting the database to be dropped (i.e. thrown away).

List of 17 messages in thread
TopicAuthorDate
Interpreted Languages?      Andy Neil      11/11/11 16:08      
   Sometimes it's hidden      Richard Erlacher      11/12/11 00:04      
      p-code      Per Westermark      11/12/11 05:04      
      P-code and others      Oliver Sedlacek      11/15/11 00:03      
      interpreter/compiler      Joseph Hebert      11/15/11 22:35      
         Debatable      Oliver Sedlacek      11/17/11 01:12      
            Not necessarily machine code      Matthias Arndt      11/17/11 01:19      
               Definitely debatable      Oliver Sedlacek      11/17/11 04:43      
                  Ofcourse not      Matthias Arndt      11/17/11 10:22      
   runtime errors      Jan Waclawek      11/12/11 05:22      
      You can't      Per Westermark      11/12/11 05:42      
      You missed the point!      Andy Neil      11/12/11 05:42      
         Not always worth it with interpreted languaes      Per Westermark      11/12/11 06:11      
            I like your thinking      Justin Fontes      11/15/11 10:40      
               Many FORTH implementations are interpreted, aren't they?      Richard Erlacher      11/15/11 11:08      
                  Forth      Per Westermark      11/15/11 11:29      
   Maybe a comparison?      Justin Fontes      11/15/11 10:14      

Back to Subject List