There is no technical standard that defines a scripting language. It's just a word that is defined by common usage, and like any other word in common usage, there is no guarantee that all the usages are consistent. Tackling your specific questions:
The dynamic code generation they are
talking about is machine code. In a
classic interpreted language (think
BASIC interpreter), each time a line
of a script is executed, that line is translated on the spot
into native machine code. It's more complicated now, since many scripting languages will be translated into byte code for a virtual machine, and the byte code may get cached.
This is where it gets very fuzzy,
and changes with time. In ye olden
days, pretty much every scripting
language was a classic interpreted
language. Nowadays many use byte code, virtual machines, and may use Just-in-time
compilers. At that point the line between
interpreted languages and compiled
languages is blurry. Still, I don't
know of any language commonly
referred to as a scripting language
that is compiled in the classic
sense of a one time conversion to
native machine code.
Languages commonly called scripting
languages usually provide a suite of
high level data structures like
sets, lists, and dictionaries, as
well as features like regular
expressions. There are interpreted
languages that don't provide those
high level features, and they
usually aren't called scripting
languages. I don't think many folks
would refer to interpreted BASIC or even UCSD Pascal as
a scripting language.
There are a few possibilities (last one would be the easiest and most sensical, in my opinion, except if that's meant to be a long-term and reusable piece of code):
Use a web-testing framework
They are meant to do this sort of stuff, so obviousy they do it well. But I think they're a bit heavyweight for what you want to do. For instance, Adel recommended Selenium, which is a great testing tool but a freaking monster to get started with (and will fire up browsers, except if you use the new WebDriver-based API that will use a browser-less driver like HtmlUnit.
So, that's why I'd recommend, if you go down this route, to just use something like HtmlUnit (which you could invoke from a Java program, or from any other JVM-based language: Groovy, Scala, Clojure...). But I'd still regard this as relatively heavy.
Use a general-purpose scripting language
Python, Perl and a herd of others will allow you to write this from scratch quickly, or to reuse an existing library to implement your own HTTP client to send your POST
requests.
If this think is going to be maintained in the future, I'd go with Python. If it's going to be quick and dirty, Perl is a hacker's best friend (and CPAN its favorite sledgehammer).
Use bare shell scripting and something like curl
Go even more minimalistic: bare shell-scripting to process your inputs and format your data, some curl
invocations to POST
to the server, and voila!
If you're on Windows, Powershell will be your friend.
There are hundreds of other possibilities to do this, I barely mention the ones that come to mind and that I'd use.
If that was my task, I'd probably write an ugly command line that:
I'only use a more advanced testing framework if:
- I'm likely to be asked to do this again for different data formats,
- I'm likely to be asked to do this again for different datasources and target DBs,
- I'm likely to be asked to do this often.
In that case, a more engineered approach does make some sense, for maintainability and extensibility.
In all cases, remember to backup that script and pass it along, and to document it (a README
would do) and implement a usage
. If they have one, version it in their SCM.
Note: another reason why taking the web-form submission approach might be better than the "direct to SQL" approach is that the server receiving the form might be doing extra checks you aren't aware of at this time.
Not saying it's the case, but maybe security wasn't the only reason.
Good luck with the job.
EDIT: just noticed you tagged this as "PHP". I don't really see why, as that would imply for the code to be server-side (well, you could use PHP for any kind of scripting, but why do this to yourself?)
Best Answer
In CPython, allocation of tuples (basically immutable lists) can be slightly faster than an allocation of the equivalent mutable type with the same items. I vaguely remember similar rumors about immuable sets, but
timeit
didn't confirm it. Tuples can also be smaller than lists, from a few bytes to 50% (if you hit a spot where the list had to resize, and doubled its capacity to speed up future growth). Moreover, tuples and sets are - in some contexts - subject to peephole optimizations which allow creating the object once and re-using it instead of re-building it every time.But that's mostly peanuts. It's not why we use these types, at least usually. If ever, these differences are only invoked when seriously optimizing. It's not an aspect I usually consider when deciding for either, especially since there are other benefits, not to mention the enormous semantic impact.