Design Element
Comment on "Sanity Checking for Scripting Languages"
by David — Dec 26
Those compile time checks are a definite plus. I think this is one of the main reasons why I'm not a big fan of scripting languages. It just makes things seem disorganised and chaotic.

It can do, yes, which is why organization is of paramount importance. But you're missing out on truly enormous productivity gains by dismissing scripting languages.

Structured and written properly (with all the aforementioned naming and organizational tactics), you can typically write solutions within a scripting language within a fraction of the time that it takes for the same ObjC/C++ write-compile-test sequence (which of course, is done all day long in major projects). One reason for this is that scripts allow you to solve problems in fundamentally different ways than most compiled languages allow for.

Of huge importance: you can write and edit your scripts as your host application is running! So you can implement functionality without a compile, and see the results in real-time, without having to quit and relaunch the application. (Thus, state is retained and current logging remains intact.) For big projects, this can save hours in every single day. This can bring about certain emergent sorts of behavior and interesting features to your designs that would be next-to-impossible to see with traditional languages. Also, you can implement new functionality in a more human-like, buzzword-compliant language that doesn't care if you cast to void* or not.
Back to "Sanity Checking for Scripting Languages"
Design Element

Copyright © Scott Stevenson 2004-2015