All Dried Up?

I haven’t forgotten about this blog.  But I have been struggling to rationalize its existence in the face of so many great scripting blogs out there.  I thought a unique and possibly helpful niche would be inter-language scripting.  Hence the scripts which leverage two or more languages to accomplish a single task or goal.  But it doesn’t seem this is of much use to anyone.  Indeed, after looking at it several times, it looks more like an oddity or some exercise in cleverness, rather than something of geniune use to anyone.  If you can think of something that might help focus this I’m all ears.  Otherwise, I’m just going to let this blog ferment for a while on its own.

A Portable LISP Interpreter?

The very first programming language I touched was GW-BASIC, then COBOL, then QBASIC, then FORTRAN, then LISP and PASCAL and C++ and Java, and on to newer things like Visual Basic, ASP, PHP and Javascript, XSLT and so on.  In that chronological order, actually.  But of all those, the one that grabs my attention when I hear its name spoken is LISP.  I spent almost 15 years focusing my programming time on AutoLISP, Visual LISP and dabbling quite a lot with Franz, XLISP and CLOS, but kept going back to Visual LISP (or “VLISP”) because of it’s strong association with graphical environments (AutoCAD).  The combination that Vital LISP brought to the table from the work of Basis Software, later acquired by Autodesk, opened up a whole new world for joining the flexibility and power of AutoLISP with the COM fabric exposed by Windows.

I always loved the way AutoCAD and the VLISP engine provided the substrate for running scripts within AutoCAD much like how Java apps run on the JRE or how PowerShell runs on .NET CLR.  But actually, it dawned on me that a more ideal solution is what you get with KiXtart.  The engine is self-contained and extremely lean and responsive.  Robust and Streamlined, would be two words I would use to describe it. 

Unlike WSH or PowerShell, you don’t have to install anything in order to start executing KiXtart scripts.  You just need access to the Kix32.exe runtime and it just “goes”.  The runtime can be across the network and you can even invoke a local script using a UNC path to the runtime.  It’s ridiculously easy to sit a computer “A”, and run a script sitting on computer “B” using the Kix32.exe on computer “C”, and it works fine.  Ruud van Velsen indeed deserves accolades for not only making this work so well, but for maintaining the vision and direction that keeps it alive today.  Indeed, the KiXtart community is as strong as ever and the online presence is simply amazing.

Why couldn’t there by a similar approach to a LISP runtime?  Is there such a thing?  Every LISP runtime I’ve seen requires labor to set up and there’s the added issues of which dialect is used (XLISP, Franz, Common, NewLISP, etc.).  A stripped-down core library would be fantastic.  Something like AutoLISP but without the AutoCAD-specific functions.  Replace those with added file system, registry, environment, process and WMI interfaces, and the rest tied to COM or even .NET, and, well, geez.  I’d be happy.  I wish I had time to build such a beast.  If anyone has a project going on this, I’d be more than happy to help you test it out and provide feedback.  I’m sure this is a tall order though. 

Just a thought.  Ok, I’m going to bed now.

So, what do you get with that PowerShell Combo?

Fries? A drink? A kids toy?  As it turns out, not much.  This is just one example of what has been a trend that really bothers me about the so-called “examples” of PowerShell being published on the net lately.  Most are focused on WMI queries (WQL), or COM marshalling using the New-Object –COM method.  This really doesn’t do anything innovative or beneficial beyond learning a “different” way to code.  All of the WQL examples are simply search/replace code chunks which look almost identical to VBscript examples.

VBScript

Set objOutlook = CreateObject("Outlook.Application")
Set Namespace = objOutlook.GetNamespace("MAPI")

For each f1 in NameSpace.Folders
    wscript.echo f1.Name
Next

For each objFolder in NameSpace.Folders
    For each f1 in objFolder.Folders
        wscript.echo vbTab & f1.Name
    Next
Next

PowerShell

$Outlook = New-Object -com Outlook.Application
$Namespace = $outlook.GetNamespace("MAPI")

"{0} Root Folders:      " -f $Namespace.folders.count
foreach ($Fl in $namespace.Folders) {
    "   {0}" -f $Fl.Name}
""
foreach ($Folder in $Namespace.Folders) {
    "`'{0}`' subfolders: " -f $Folder.Name
    foreach ($fl in $Folder.Folders) {
        "   {0}" -f $Fl.Name
    }
}

I’m not at all trying to “bash” PowerShell.  It’s a cool language, but it has it’s issues that bother me.  I don’t consider it a classic or “true” scripting language as much as programmatic macro language.  Most of the benefits it provides via brevity of code are derived from cmdlets, which are similar to making DLL’s for COM extensibility, or UDF files for KiXtart, and so on.  Blah blah blah.  whatever.  I’m no pundit, so what I have to say doesn’t really matter that much really.  I forgot what point I was trying to make.

Back from the Brink of something

What is a "brink" anyway?
Web dictionaries describe it as a "region marking a boundary".  But what is a "boundary"?  For that matter, what is a "region"?  I could go on, but who cares.  This is where I'll be posting script stuff.  Again.  And for those who got pissed off at me last time:  Too Fkking bad.