Yes, the lack of full IDE support in scripting languages can be a major hurdle, to the point where otherwise useful features of a language go unused in larger projects because there is no way to visualize those features or structures within the IDE.
For example: creating classes for OOP in Lua. Dangerous to do on larger scales because your text editor of choice won't show you "member functions" within your "classes". Which means you spend half of your days doing text searches for your functions, meaning that OOP actually becomes a productivity killer.
(BTW, Lua developers, check out SubEthaEdit for its highly useful Lua module.)
If you're creating more than a handful of functions in a scripting language, I think it's essential to start building a library of debugging routines, assertions and the like, including logging out the state of globals, printing out the stack calling chain, etc.
Also required is an extremely strict adherence to a naming system, regardless of the length of your variable/function/class names. Your scripting system generally won't care that your new variable "fooo" doesn't exist (it's a nil) and you probably won't pick it up until one of your Asserts find it.
Scripters may want to read Code Complete, especially the chapters on naming and project organization. It's even more relevant to scripts than it is for traditional, lower level languages.
Another trick is to use wrappers when loading scripts. Instead of calling the language's native load function, instead call your own wrapper which can remember details about the file (path, caller, etc.) and then attempt to load the file with error checking. If anything goes wrong, the trace can be logged to file.
When your application exits, files can also be checked off through this system to see if they've been cleaned-up properly or not. (Resource management is notoriously tricky in some scripting languages.)
Which brings me to the next trick: separate your code in to far more files than you would normally do in a compiled language. Why? Because it only takes one tiny mistake to screw up an entire script so by parcelling out your code into smaller sub-sections, you automatically help pin-point which file the problem belongs to. Then put all the sub-files into one folder for organizational purposes, where the folder is treated as a module or a unit.
Scripting languages are clearly the way of the future and are being used to extend applications in all manner of ways, but we need the tools to catch up. But that's supply/demand, so...
Finally, how to spend a day debugging in Lua:
local table = {};
That's it. No "keyword" warning error, no indication whatsoever that anything has gone wrong or that you've actually killed off a major package in the language. Heh.
by David — Dec 24
For example: creating classes for OOP in Lua. Dangerous to do on larger scales because your text editor of choice won't show you "member functions" within your "classes". Which means you spend half of your days doing text searches for your functions, meaning that OOP actually becomes a productivity killer.
(BTW, Lua developers, check out SubEthaEdit for its highly useful Lua module.)
If you're creating more than a handful of functions in a scripting language, I think it's essential to start building a library of debugging routines, assertions and the like, including logging out the state of globals, printing out the stack calling chain, etc.
Also required is an extremely strict adherence to a naming system, regardless of the length of your variable/function/class names. Your scripting system generally won't care that your new variable "fooo" doesn't exist (it's a nil) and you probably won't pick it up until one of your Asserts find it.
Scripters may want to read Code Complete, especially the chapters on naming and project organization. It's even more relevant to scripts than it is for traditional, lower level languages.
Another trick is to use wrappers when loading scripts. Instead of calling the language's native load function, instead call your own wrapper which can remember details about the file (path, caller, etc.) and then attempt to load the file with error checking. If anything goes wrong, the trace can be logged to file.
When your application exits, files can also be checked off through this system to see if they've been cleaned-up properly or not. (Resource management is notoriously tricky in some scripting languages.)
Which brings me to the next trick: separate your code in to far more files than you would normally do in a compiled language. Why? Because it only takes one tiny mistake to screw up an entire script so by parcelling out your code into smaller sub-sections, you automatically help pin-point which file the problem belongs to. Then put all the sub-files into one folder for organizational purposes, where the folder is treated as a module or a unit.
Scripting languages are clearly the way of the future and are being used to extend applications in all manner of ways, but we need the tools to catch up. But that's supply/demand, so...
Finally, how to spend a day debugging in Lua:
local table = {};
That's it. No "keyword" warning error, no indication whatsoever that anything has gone wrong or that you've actually killed off a major package in the language. Heh.