One would expect that you should use the tool-specific language to create your scripts. Else, I don't know how your scripts could run.
That having been said, remember that automation scripting is just another form of programming...and in that vein, good programming practices would dictate some semblance of commenting your code...or, in this case, your script. Your company may already have set standards for coding...and if such is the case, then you should do your best to adhere to those standards.
Cyberentomological Detection, Prevention, and Eradication Specialist
"The single biggest problem in communication is the illusion that it has taken place."
-George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950
If you have a choice I would suggest you choose a tool that allows you to script in a non-tool specific language.
Tool specific languages have an isolationist effect with no discernible benefit. If your tool uses some variant of VB for instance, there is a vast choice of resources on the net that can help with problem resolution. There are loads of Microsoft MVP solutions posted in newsgroups and you benefit from cross fertilisation of knowledge with people who are using the language for a wide variety of purposes. You also learn a language which is not reliant on having a very expensive piece of software on your desktop for it to be useful.
I do not see testing as an application that needs a specialist language and can only imagine that this phenomena is more down to the various vendors marketing strategies than anything else.
Most of the Test Automation tools's syntax & way of coding is similar to any one of the common languages. For Example, WinRunner coding is similar to C, Visual Test coding is similar to VB.
I didn't use Silk Test. If you know 'C' or 'C++' well, Learning winrunner would be easy. If you know VB, Learning Visual Test is easy for you.