Friday, May 22, 2009

What is a Scripting Language?

That's a good question.  Far more knowledgable people than I have pondered this question.  It shouldn't surprise anyone that I'm not exactly a "pundit" on this (or pretty much any) subject.  But  I have spent the past 25 years in and around writing code of various ilks.  In college I spent plenty of time with compiled and interpreted languages.  The longest dance I've had to date was with LISP and it was a good time.  I'd like to think I've learned something along the way.

Back in college, the definition of "scripting" in contrast to "compiled" applications was sketchy, but the general idea was pretty clear to us.  It seemed that the differentiation fell into at least the following general guidelines:
  • Scripts were loosely (or un-) typed, while compilers were strongly typed
  • Scripts were designed for quick development and quick results
  • Compiled languages were designed for process efficiency and feature packaging
  • Scripts were aimed at part-time developers, like Sys-Admins
  • Compiled apps were aimed at programmers and software engineers
  • Scripts were interpreted at runtime, or semi-compiled (i.e. p-code, etc.)
But times have changed.  Scripts now bear many of the features (and burdens) of compiled languages.  The focus of many has been on the side of software programming, rather than system administration.  Many still exist that strike a good balance between complexity and flexibility.  But the definition itself, if there ever really was one, seems to be shifting gradually.  The bullet list above would have fit well in the 1990's, but now I'd bet some would argue over some of the specifics.  Maybe I'm holding on to old ideals too long.

If I had the time (and desire) to build my own scripting language, it would fit the following rules:
  • The "engine" would be self-contained (no installation required: KiXtart)
  • It would provide all of the standard functions for strings, math, dates, file systems, data source providers, and so on.  For example: I shouldn't have to write code to calculate date differences.
  • It would support objects and class templates, but not require them
  • It would support try/catch/finally (e.g. PowerShell v2)
  • It would provide input and output UI tools (e.g. VBScript: InputBox, MsgBox)
  • It would provide exposure of environment objects (e.g. KiXtart macros)
  • It would support robust string manipulation (e.g. PHP, Perl)
  • It would support list structures and structs (LISP, Scheme)
  • It would support obfuscation and tokenization (KiXtart, LISP, .NET)
  • It would rely on a consistent syntax structure (PowerShell)
  • It would support pre-compile library fetching without explicit inclusion (detect API invocation statements and automatically include references)
  • It would natively support dynamic recursion (LISP)
  • It would support in-line expression branching (LISP: (cond) )
  • It would support lambda and matrix expressions (LISP)
  • It would scratch my back before I knew it itched (ok, just kidding)
That's a tall order.  Maybe when I retire and the kids are grown and moved out, I can spend my golden years slumped over the keyboard and make this happen.  Oh wait... I forgot: I can't retire.  I can't afford to.  Well, like the Joe character from Joe's Garage (Frank Zappa), I can dream my imaginary perfect scripting language, that probably no one else in the world would use besides myself.
Post a Comment