Thursday, December 3, 2009

My Ideal Scripting Language

I’ve sat around and been pulled into more conversations than I can count regarding what my “perfect” or “ideal” programming or scripting language would look like and how it might work.  So, I thought I’d take a stab at.

It would involve some built-in enumerations for things like operating system platforms.  For example…

iOS_OverPriced = “Apple OSX”
iOS_OverZealous = “Microsoft Windows”
iOS_OverHyped = “Linux”

Functionally, it would probably be somewhere between PowerShell, VBScript and KiXtart with more emphasis on KiXtart.  But it would also include dynamic typing and evaluation from LISP (e.g. cond() and apply() functions for example, but also lambda() and mapcar() … why not?).

The script engine would be self-contained and portable, and would run on any modern OS without any installation required.  Something like how KiXtart runs on Windows already.  The same code syntax regardless of platform, but allow for extensions.  Sound familiar?  I thought so.

No type-defs or declarations required, but optional (like VBScript and KiXtart).  Consistent syntax regardless of noun/verb modal use or situational use.  For example, one example, no requirement to prefix “Set” before instantiating an object.  Because that is just stupid fucktarded 80’s mentality, that’s why.

The syntax structure would be aimed at administrators, not programmers.  KiXtart is aimed at administrators, which I *LOVE*.  PowerShell is aimed at programmers.  I don’t count cmdlets as programming, unless you’re making them, and if you’re making cmdlets, you’re not likely a true administrator, you’re a closet programmer at the very least.

The engine component would support encoding and obfuscation features for code protection as well as compression, using auto-detection for runtime expansion.  There would be a default system log for all scripts unless explicitly overridden by the script itself.

It would support .NET interfaces and invocation, and would be packaged as a DLL or suitable component for OSX, Linux and so on to allow for it to be marshalled or invoked by other processes.

It would include functions for all standard types such as numerics, simple and complex arithmetic, strings and string manipulation, dates and regular expressions.  There would be no function left out from the other languages mentioned above which would result in “going backwards” for a particular functional use.  For example, calculating DateDiff() with PowerShell (don’t even get me started).

I’m sorry, but going from this…

days = DateDiff(“d”, date1, date2)


to this…



$a = New-TimeSpan $(Get-Date) $(Get-Date -month 12 -day 31 -year 2006 -hour 23 -minute 30)
$days = $a.Days

Is mind-numbingly irritating to me.

Oh well, dinner calls.  Gotta run.  More later…

1 comment:

Alan Kaplan said...

Absolutely true! Kixtart was never native, but was once made the best logon scripts. Later we moved to vbscript.

PowerShell is not an administrator friendly. It is hard to imagine the average admin coming up with a PowerShell logon script -- even by pasting together bits of other peoples code. The only bit of good news is that our Microsoft rep says that vbscript will eventually become legacy, like NT batch file suppor. Knowing how to write a batch file already makes you an old timer. How long before vbscripting is seen the same way?