Why PowerShell is a Big Deal (In my own feeble words)

If you've followed my blog for a while (my apologies, of course) you're probably wondering just what the **** I'm aiming for.  That's a fair question, because, to be honest: I really don't know.  It's a venting machine for me, I suppose.

For a long time I ranted on about Autodesk products and AutoCAD customization, then it turned into Autodesk product installation and licensing management, and networks, and then I had an unplanned career change dropped on me from nowhere. I had to make a shift into the "mainstream" IT world and learn Microsoft tools and things entirely different than I was accustomed to. Since then, my professional and personal life has been a blender, tossed into a woodchipper and fed into a meat grinder.  Messy, yes.  A disaster?  That depends on how you define the word.  Blah blah blah, yes, I'm aiming for a point here somewhere, please be patient?  Your call is important to us...

I started playing with program code back in 1986, while working as a drafter in the Marine Engineering field.  That's fancy terminology for designing things that go on ships.  In my case: U.S. Navy ships.  Big. Heavy. Gray.  Smelling like oil. And usually parked in some rather unappealing locations in the worst kinds of weather.  We would go aboard, sketch up stuff, go back to our hotel, eat and drink (okay, mostly drink) and then return to the office and formalize a set of design drawings to accomplish a "retrofit" of something.  A "retrofit" is basically replacing something to improve some aspect of the ship (performance, capability, living conditions, etc.)

After CAD took hold among the DoD world, it took much longer for the mainframe and workstation era to pass and open the door to the PC world, than it did in other industries (i.e. AEC).  It wasn't until around 1987 that the Naval Shipyards would even "allow" the use of AutoCAD for any official drawing contracts.  At first it was only allowed for title sheets, materials lists and anything "non detail design".  Eventually, they gave in and began replacing all the old DEC, Sun and IBM crap with shiny new IBM-PC boxes and much cheaper software.  In all, it saved them enough on budget to buy a small country (they probably did just that).

I got my first taste of "real" programming in 1987 from reading a book on AutoCAD R10 and learning AutoLISP and a little ADS later on. AutoLISP was it.  Even while going to college for my IS degree, and soaking up C/C++, and all that, I couldn't ignore the flexibility and dynamic personality of LISP.  At the time, it was like trying to remain focused on a mail delivery truck while I kept my eyes on the '67 Camaro SS parked on the side.  Not much competition in my mind.  But alas, marketing won and LISP began a slow decline from the 1990's into the mid 2000's.  Microsoft's unstoppable licensing machine eventually mowed down the momentum behind anything besides Visual-This and That.  I can't pick at the technological appeal either, so I'm just whining I suppose.

Soon after the mid 1980's I picked up BAT and KiXtart on the PC side, and Bash/Korn and Perl on the UNIX side (mostly at school).  Then I ran into the database world and began mashing AutoLISP with AutoCAD CAO and ObjectDBX, which dropped me into a rat hole called Visual Basic.  It was fun and lasted me through the mid 1990's very nicely.

Long story short:  I gradually became jaded by every new programming language coming out.  It seemed like yet another attempt to get the junkies hooked on a newer drug and keep the marketing departments employed.  Tech conferences kept shoving one new language or toolset after another and spending tons on spiffy ads and graphics.

I thought PowerShell was just that.

I was dead wrong.

For years, my colleagues would roll their eyes at me, when I'd start pontificating about "Microsoft should __", following my third cup of coffee.  As if anyone in Redmond gives a shit about some annoying guy named Dave out in the redneck state of Virginia.  My usual rants involved the lack of cohesion and consistency among the various command tools.  Things like NETSTAT, NET this-or-that, IPCONFIG, NTDSUTIL, DSGET/whatever, DIR, and then CMD and BAT scripting weirdness.  I kept saying "they need to clean this shit up!" and then I would fade off into a muffled blubbering of incoherent words and slurping coffee (cold and stale, usually).

Even after I jumped on the Monad open preview bandwagon, I didn't get it.

I read articles and still didn't get it.

I bought books and still didn't get it.

I went to Microsoft TechEd 2011 and 2012 and didn't get it. (I did get a few t-shirts though)

Then I read a few blog posts by Jeffrey Hick, Jeffrey Snover, and Don Jones and a few others.  And then after studying for some MCITP/MCSA exams, it hit me like a train:  THIS is what I was begging for.  Granted: It hasn't reached the goal line yet, but damn if it hasn't made it a long way down the field.  In fact, from my poking and inspecting, I would dare to say it's in the Red Zone and there's still plenty of time on the clock. (sorry to all non-Football fans, I feel you - but I couldn't think of a better analogy this late at night).

I've been dragging ASP, BATch, VBscript and COM around like a two-year old child with a dead pet on the other end of a worn leash.  Thinking it was still alive and wanting to go play outside.  Now I know what that smell was.

I'm in.  My focus from here on out will be to deprecate my use of anything besides PowerShell and ASP.NET.  If your eyes are rolling in pity right now, I apologize.  I'm really late to the party, so I have a lot of drinking to catch up on.

Namaste.

Why Every SysAdmin Should Learn to Write a Script

I'm a bit overdue for a perceptual conceptual brain-twisting deep-dive article, and caffeine seems to always push me in that direction, so it was time.  And besides, I've been torquing my brain to the limits working a huge article series for 4Sysops on Troubleshooting Configuration Manager clients.  On top of that I'm in the final throws of my next book, and no shortage of "real" work at the office to contend with, and trying to maintain sanity with four kids still at home, and well, it'll be worth the wait, but I may need a stiff drink when it's wrapped up.

So, without further adieu...

Why the Title?

There's no shortage of articles, blogs and whatnot that tout the "benefits of scripting and coding" for anyone who spends time on a computer.  Okay, maybe they're mostly aimed at those who earn a paycheck spending time on a computer, but that's okay too.  Most of the articles I've read however seem to focus on the benefits of automating common tasks, as well as extremely difficult or complex tasks.  That's fine also, but there's more to it than that.  Much more.  To me they're kind of missing the main point:

Writing a script teaches you a particular way of thinking.

Sure, automating tasks pays pretty well, but there's more to be gained by an everyday computer technician from learning to write even the most basic script. One of the main reasons, indeed THE reason, that I chose the title for this article has nothing to do with automating tasks at all. Let us drink the Kool Aid of digression and digress with me for a bit, mmkay?...

A Different Kind of Thinking

Writing software code, whether it's to be compiled or interpreted, involves a process of thought.  Granted, there are some variations of the thought process as it pertains to a particular programming language, as well writing functional, procedural or object-oriented code, but the process itself; the process of telling the computer to perform certain actions, remains.  It's a logic process.

If This is True: Do That  /  Otherwise: Do something else...

Disregarding semantics for a moment, the flow of logic is roughly the same whether you work with C++, JavaScript, LISP, Python, Ruby or whatever.  Picture the following example scenario:

Task: Instruct a Robot to retrieve a box of cereal from a cabinet on the other side of the room.

That sounds easy, right? "Hey, robot.  Get me the box of cereal."

But the robot doesn't move.  It needs to be told:

• where to go
• how to get there
• what exactly to retrieve
• how to actually retreive it
• where exactly to go next
• how to go to the next location
• when to perform each step

The only basic questions it doesn't absolutely need to ask are the who and why aspects. For now, anyway.  Let's ignore the possibility that it's a super-advanced robot that understands these things. Let's instead go with a robot that was just born and has to be taught like a baby human would.  These steps come with a few qualifying pieces as well:

• where to go: relative to current location
• how to get there: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• what exactly to retrieve: which object(s), means for identifying or locating
• how to actually retreive it: grasp, slide, push, pull, tip, scoop / carry, store, clutch
• where exactly to go next: relative to current location
• how to go to the next location: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• when to perform each step: now/immediate, x minutes/seconds from now/from previous step

It should make you pause for a moment and begin breaking down the sequence of tasks in detail:

1. Turn [n] degrees to your [right/left]
2. Move forward approximately [x] feet and stop
3. Turn [n] degrees to your [right/left]
4. Move forward approximately [x] feet and stop
5. Raise arm upward to [x] degrees from default position
6. Extend arm forward [x] inches
7. Grasp cabinet handle
8. Pull grasped handle, swing arc to [left/right] until door is opened [x] degrees from starting position
9. Release handle
10. ...

You get the idea.  Those of you that have actually programmed machines like this already know that I'm glossing over a lot of detailed steps in between.  This is actually the basis for how a programming language is developed: step by step, nouns and verbs. Then come the adjectives (gently, loud, etc.), until the language is matured enough to accomplish the general class of tasks it was intended to address.

Side Note: When asked "what is the best programming language?" the answer is: "There is no such thing as a 'best programming language'".  Every language is better at some particular tasks than others.  A programming language is a tool.  A tool is a means for accomplishing one or more tasks. Each tool is conceived and built to address a particular set of tasks.   

Contextually, some languages are "better" to master with regards to job opportunities or specific projects.  From a technical point of view, the concept of "better" depends on specific comparisons of individual features as they align with a set of specific tasks which are to be accomplished.  The more general or multi-purpose capability a particular tool becomes, the less specialized it becomes at the same time. 

That was a lot of mumbo-jumbo, sheesh.

You may start letting your mind wander into additional challenges, like navigating stairs, odd angles, and so on.  Hopefully another thought crossed your mind: How much we, as human beings, take for granted this little stuff.  Imagine what someone fighting through physical therapy has to deal with as they learn to walk or speak again following a major injury.

In most respects, this way of thinking forces you to shoehorn your intentions into the mouth of the beast we call a computer. The point is that when you're forced to structure your thinking in someone else's terms, it also forces you to think more clearly about what it is you're trying accomplish.

In many respects, it forces you into a serialized or sequential mode, even if your goal requires solving parallel processes.  You have a Start and a Finish.  A beginning and an end.  Initialization and termination. An Alpha and an Omega (for you religious folks, a little humor, pardon me). Regardless of having to contend with seemingly random or asynchronous sub-tasks, the overall context has (or should have) a defined start and end.  If you're looking to run a program that just goes off and does a bunch of unrelated things; does a lot of unrelated and undefined things, and never ends, that's been done already: It's called politics.

Let's put this into somewhat of a "real world scenario" for a  moment. A

Example: Finding all Files in a Folder that Contain a Particular Text Value or Numeric Pattern

This is a very common task indeed.  Whether it's finding documents that contain a reference to a particular contract number, or data files that contain a numeric pattern, or sales records with a particular date, log files that include a specific name or code, the logic for pursuing the answer is pretty much the same.  What differs is the trivial stuff like formats, locations, and the periphery like environment and concurrency limitations.  I say "trivial" in the sense that those are relatively less important than the primary goal being sought.  I'm fully aware that in many cases those so-called "trivial" extraneous things can become the biggest headache to deal with.  Okay, enough blabbering from me.  Let's dissect this creature...

What are we trying to accomplish here?

1. We need to identify what we are looking for: ____
2. We need to identify where to look for it: ____
3. We need to identify what to do when we find it: ____

There are millions of other things we can do, and may need to do, in addition to these basic questions, but in most cases these are the three most important questions to answer.  You could boil them down into two primary categories: Target and Action.  What is the target and What action do we take on it (or because of it)?

For this example, we'll keep it simple and go with the following parameters:

Find all instances of the text value "CNX-10114025" within all of the documents contained in the Folders located on server FPS0025 under the shared folder root of "Contracts".  The target UNC path then becomes "\\FPS0025\Contracts".  Maybe a quick inspection of the folder structure reveals that there are nested folders which will need to be scanned, as well finding that there are an assortment of file formats to be found:

• Microsoft Word, Excel, of various versions (.doc, .xls, .docx, .xlsx, etc.)
• ASCII Text (.txt)
• XML files
• HTML source files
• PowerShell scripts (.ps1)

You probably stared at that list and immediately began to think through the process for opening, reading, and parsing each file type.  You're already staring at the trees, let's get back to the forest.

Here's what you should have thought:

1. Access the root folder
2. Look for files in the root folder
3. Check each sub-folder
4. Look for files in each sub-folder
5. Check for the next level of sub-folders
6. Look for files in each sub-folder
7. Wash. Rinse. Repeat

An average programmer or scripter (script-writer? script-kiddie? I can never figure out what the proper term is anymore) would get to step 4 and immediately blurt out "Recursion, bitches!" and then quiet down after realizing they just upset everyone else in the library.  I happen to be sitting at a table in our "central" public library actually, so that's why I made that connection.  I haven't blurted out anything yet though.

Forget recursion for the moment; stay focused on the forest.  The trees will come later.  And, yes, I know that the preceding sentence is completely illogical, let's keep moving along...

Are you seeing the process yet?  If you're following along with my mindless rambling, you're probably nodding in confirmation of understanding that you have to think it through in an orderly fashion.  The key here is "orderly" (i.e. sequential.  serialized.  linear).

Side Note: Yes, I know that there are non-linear, amorphous, parallel and even polymorphic/non-linear/parallel problems to be solved, but this is Dave 101 and that course isn't until next semester (if ever).  Context is everything.  The context here is: how does writing a script benefit a systems administrator who's never considered writing a script before now.

Pseudo-Code to the Rescue

Most programmers will have likely put there head into both hands and moaned at reading that line above.  The prevailing view of pseudo-code is that it's for beginners.  Noobs.  Training-wheels.  And in some respects that's true, but it works. No reasonable programmer or scripter can argue that writing pseudo-code is detrimental to anything besides (A) their ego and (B) their time.  I've seen it used by some of the best and brightest programmers when conditions were sufficiently warranted.  What did that mean?  I mean that when faced with an incredibly complex task to accomplish, pseudo-code can help map out the primary steps and it can bring clarity to the major components of the impending code to be written.

What is Pseudo-Code Anyway?

Rather than explain it, I'll just show it:  First, here's a chunk of actual program code...

If Not amx_InstallRegKeyExists ( regKey3 ) Then
   dPrint "info", 0, "AMX is not installed. Proceeding with install sequence."
   If Not amx_PreReqsFound ( arrReqIDs ) Then
      dPrint "info", 0, "Installing AMX prerequisite components..."
      p1 = amx_InstallMissingPrereqs ( arrReqIDs, False, vbMinimized )
   Else
      p1 = True
      If amx_InstallSequence ( arrAppIDs, False, vbMinimized ) = True Then
         p2 = amx_InitRebootSequence()
      Else
         dPrint "error", Err.Number, Err.Description
      End If
   End If
Else
   dPrint "info", 0, "AMX is already installed. No action required."
End If

Now, let's write that in pseudo-code:

1. If application "AMX" is NOT already installed (then...)
1. install prerequisite software items
2. install AMX application
3. check that everything installed properly
4. reboot the computer
2. Otherwise (else...)
1. nothing to do, exit cleanly

That's it.  Pure and simple. Now, the question you may ask is "Hey, dumbass: where do I buy a book on this 'pseudo-code' programming language?".  You don't.  You can't.  There's no such official programming language by that name.  It's a term used to describe the writing of program instructions in human-readable terms. It's like a "faux diamond", "pleather jacket", or an "honest politician". It's "fake". The word "pseudo" means "not actually, but having the appearance of...", or fake, so you get the picture.

Master or Commander?

Am I saying that you need to spend a lot of time mastering the art of writing scripts?  No.  I'm only suggesting that learning how to write even one script successfully will help you in the long run.  It's sort of like walking a mile in the computer's shoes.  I'm not going to trick you and deny that writing scripts isn't both addictive and lucrative.  The more you write the more tasks you'll think of to use them on.

Pointers

Some of the sites I look to for help and inspiration when working on new scripts (if I don't have code laying around from twenty years of tinkering with it):

• Microsoft TechNet Script Center
• PowerShell.com
• Rob van der Woude
• PowerShell Code Repository
• ss64.com 
• Dr. Scripto's Script Shop (Microsoft)
• MSDN VBscript Language Reference
• MSDN ADO Code Examples
• ActiveXperts.com

Why Comparing Visual LISP to VBA is a Waste of Time

Warning: This post is going to go so nerdishly geeky - that even I might have to put new tape on my glasses.

Jimmy Bergmark posted a really cool (and useful) tabular comparison of functions/methods between Visual LISP and VBA as of AutoCAD 2013.  It stirred up some thoughts, and emotions, in me about the path each language has taken (or not taken).

As I scanned my eyeballs down each row, the three functions that caught my eye were: (apply), (lambda) and (mapcar).  I will get to (defun) later.  And (cond) makes (select/case) look like a kid's toy.  I won't even dive into (eval), (quote) or (read).

If you're not familiar with LISP (of any flavor) these probably mean nothing.  I spent many years working with that language, even when idiots snickered and made their usual stupid acronym jokes about it (nerds can be so insensitive).  However, if you were an art collector, this would be similar to dropping names like Renoir, DaVinci, and Picasso.  Or if you were a musician, like dropping names Tchaikovsky, Beethoven or Zappa.  Or if you were a writer, like dropping names Shakespeare, Heinlein or, well, you get the idea.

These three functions are EXTREMELY powerful.  They can do things that NOTHING in VB or VBA or even VB.NET can do natively.  NOTHING.  Sure, you can mimic them with a LOT of code, but in the end, at the very bottom of the process stack (or heap), they will never be the same.

LISP is by nature flexible.  But it's also dynamic.  There is a difference, even though the implications of these two adjectives overlap quite often.

If you want to pause right here to do some poking around about these functions, I'll even offer some help:

• Kenny Ramage posted a nice tutorial on (mapcar) and (lambda) here
• Common LISP web site has a nice breakdown of (apply) here
• Autodesk AutoCAD 2013 documentation section on (defun) here

Now, before you start into how (vlax-make-safearray) copies from Array(), I'll just go ahead and say that Array() is about as sophisticated against (cons) and (list) as a pile of toothpicks next to a fully-constructed log cabin.  In fact, if you want to be honest (and don't we all?), then (vlax-make-safearray) was nothing more than LISP having to be dumbed down to communicate with COM properly. Ok.  There.  I said it. (drops the microphone, hands in the air, walks off stage slowly...)

Function and End Function are about as similar to (defun) as the "fun" part, and that's about it.  The Function() declaration is static at runtime.  (defun) on the otherhand is completely dynamic and adaptable.  (defun) can be redefined at runtime, at-will.  Imagine trying to do this in VBA...

(defun MyFunction (a b c)
   (if (> a b)
      (defun MyFunction (a b c) (* a c))
      (defun MyFunction (a b c) (* b c))
   )
)

Is that a "great" example?  No.  It's just a 101 basic example.  But it exemplifies just how different these languages are.

IMPORTANT STUFF HERE...

Am I trying to say LISP is "better" than VB or VBA?

NO.

Programming languages are TOOLS.  They were always conceived and built to solve a particular set of challenges.  In most cases, when used for those very same challenges, they are ideally suited for the task.  Case in point:  Performing massively nested string manipulation in Perl or C++.  I'd take Perl any day of the week and twice on Sunday.

The original AutoCAD team (John Walker and the boys) selected LISP for a variety of reasons, but mostly because it was the most flexible language at the time. In many respects, it still is.  Particularly as it pertains (say that ten times!) to working with CAD drawings, graphic entities, precision, and object association.  But it lost it's sex appeal in the marketplace, which is unfortunate, but it was not a surprise either.

Before I start sounding like one of those guys that moans about how VHS beat out Betamax, let me say that I can see why that happened: It boils down to marketing, or the lack thereof.  Let's face it: the LISP community wasn't as interested in getting their platform onto every consumer device as earnestly as the Java folks were during the IT boom of the 90's.  Java had Sun doing its cheer-leading.  LISP had a bunch of unorganized nerds who could care less about what the "industry" wanted to do with it, so long as they could finish up their thesis lab work at 2:00 am.

Is LISP (or AutoLISP or Visual LISP) without imperfections?  No.  It could use quite a bit of TLC and modernization (especially within the narrow context of AutoCAD implementation), but it's much too constrained to be a smart business move.  Why spend more dollars on a language with fewer developers involved, when you can adopt and adapt a much more widely-used language like C#?  It just makes better business sense.

For what it's worth:  If I were handed a truckload of cash, and given the authority to direct some improvements to Visual LISP, well, I could hammer out a pretty good wishlist.  But nobody is listening anyway, so why bother?

Ok, since you asked:  Clean up the (car) (cdr) (cddr) (cdar) (cddr) (cdddr) (cddddddddr) mess.  Rename and consolidate functions to shorten the names (vlax-blah-blah-blah...).  Replace the IDE with something more recently styled.  Recode and rename the (vl-catch-all-apply) and (vl-catch-all-error-p) mess to bring it all more inline with Try/Catch/Fail, etc.  Make reactors easier to manage (like VB/VBA events).  Oh, my head hurts already.  Enough!  I can't go on.

I'm venting a bit, obviously.  And if I've upset or offended anyone who clings to their chosen programming language, I apologize.  Ok, not really, but I certainly don't want to make anyone angry.  Ok, maybe too late for that too.  Oh well.

Have a beer and enjoy the rest of your evening?

A Quasi-Scientific Analysis of DoucheBaggery

I was just thinking.  Yes: occassionally I do that.  We Americans like the word “douche” very much.  We use it in combination with other words to create nouns, verbs and adverbs in very creative ways.  But when denegrating others, in our rush to make a cool sounding phrase, we are actually cheating ourselves of using a more appropriate phrase: enema bag. 

That’s right.  We like to say “douche bag!” and other phrases like “douche-face”, “douche-breath” and “sir douche-a-lot”, or even my personal favoriate: “Lord Douchely” (only if you say it like a big, barrell-chested retired British Army Colonel with a bushy mustache and monacle). 

We don’t call people “enema bag” and “enema face” because it just doesn’t roll off the tongue quite as well.  So, douche wins.  Not because it’s actually a symbol of lowest comparative denominator, but because it just sounds better.  It’s also easier to say “douche brain” than “enema bag” when you’ve polished off a case of beer.

And some people wonder why I don’t get government study grants handed to me.  P-shaaaa!

My Favorite Scripting/Programming Languages

Just random blabbering stuff.  These are ranked in order of "most fun" to "least fun" to work with (entirely subjective of course)…

1. KiXtart 4.6x
2. PHP 5.x
3. VBScript / ASP
4. SQL / T-SQL
5. Wise Script 8
6. Javascript
7. Visual LISP / AutoLISP
8. BAT / CMD
9. PowerShell v2
10. VB.NET

Ordered by what I work with most often:

1. BAT / CMD
2. VBScript / ASP
3. Wise Script 8
4. SQL / T-SQL
5. Javascript
6. PHP 5.x (sad, very sad for me)
7. PowerShell v2 (this might change soon)
8. KiXtart 4.6x (oh, the agony!)
9. Visual LISP / AutoLISP (almost never)
10. VB.NET (almost never)

Deeply Nerdified

I've been browsing some recent publications on C# 4 and some of the new asynchronous thread features, PowerShell 2 cmdlet tutorials, as well as some of the MVC features in ASP.NET 2010.  And let's not forget LINQ either.  The more I look at "newer" language constructs the more I'm hating them.  Maybe it's my curmudgeon self getting in the way of recognizing something inherently "good".  Maybe.  And maybe I'm Elvis.

I hate to pick on any language, because, well, let's face it: I'm simply not qualified to shit on anyone's plate.  Especially what those folks are PhD's and I'm not even mopping those floors in the grand scheme of institutionalized wonder.  But LINQ bothers me in that (a) there's nothing inately wrong with SQL or T-SQL, and (b) bending one language to make non-SQL coders happy makes me want to stroll over to their cube, tear down their Star Trek poster and pour a Mountain Dew on their head.

I miss LISP.  However, I'm sure that LISP does not miss me.  To be more accurate, I miss CommonLISP and Visual LISP (a derivative subset bundled within Autodesk's AutoCAD-based product lines).  I like a lot of aspects of XML and XSLT, even though the entire transform methodology seems overly complicated to me.  I feel that PhD masterminds could've concocted something a lot more simple, direct, and operationally efficient from a code development angle.  And maybe pigs will fly out of my butt also.

But the fluidity of VLISP is just amazing to work with.  When I see someone state that Javascript is a "dynamic language" I almost puke my breakfast from two days ago right on the screen.  When I hear someone claim ASP.NET (ok ok ok, shut up: VB.NET, C#.NET, etc. etc.) are "dynamic languages" I want to make someone else throw up as well.  Come to think of it, I already do that just fine.  Moving on…

Declarative languages are inherently NOT dynamic.  Ok, technically they can be, using the Webster's definition of the word.  But even then, it depends on what aspect of using a language you are applying the adjective to before it really sticks.  Then again, it's 2010 and this appears to be the age of throwing words around like grass seed on a Spring lawn.  Few bother looking at what they're throwing.

I'm more interested in languages which can best be described as amorphous.  And LISP is (or was) the closest thing I've seen to hitting that mark.  I don't want a language that defines what I do.  I want a language that lets me define what I'm doing.  Beyond that it has to be pervasive, both in terms of scale and reach, as well as ubiquity.  LISP failed horribly on the ubiquity part.  Too many egos standing guard over the rights to let it roam in the fields and pick flowers.  It belongs in the open fields.  Maybe it's time for someone at MIT or CMU to dust it off and give a fresh coat of paint and let it out of the stable.

Eh.  Like I usually say: blah blah blah.  I'll do something serious when I win the lottery.  I don't need the bong. I'm high on life.  Now, ask yourself this one question: Did any of this crap make sense to you?

Why Do Programming Languages Die?

I’ve often wondered why programmers seem to be in a hurry to declare what they’ve spent so much time and effort on as “obsolete”, “passe” and “old” as soon as the next buzzword language pops up.  I liken this to getting a screwdriver and immediately saying “well, I won’t be needing those wrenches anymore.” 

Logic would usually dictate that we add the new to the old, and expand our arsenal of logical tools (and our resumes) to enable us to tackle a broader range of problems.  But we don’t.  We “move on”.

The first programming language I ever touched was COBOL.  That was in my 2 year school, going for my AAS degree.  We spent a few weeks covering “first, second, and third generation” programming languages.  GBASIC, FORTRAN, ADA, C, PASCAL, and everyone’s favorite of favorites: Assembler.  Hold on, I have to close my eyes, take in a deep breath and sigh with a dumb post orgasmic smile for a minute, just a sec…

ok.  I’m back.  Where was I?  Oh yeah…

At the end of that educational stint I became immersed at work in an effort to break free of the shackles of what a west coast programmer had bound us to, which held us back due to region-specific focus issues.  Nice way of saying he was only concerned with making it work for his users out in Oakland.  We had different needs and “he” (they, actually) weren’t listening to us.  So, I got curious and dove into teaching myself AutoCAD R10 and AutoLISP, ADE and DIESEL, etc.  That led me on a long path of programming, and more languages.

What seemed odd to me was that the common view in meetings, classrooms, conferences, and media, is that once the new thing is out, the old has to be left behind.  After all: it’s old.  We treat people like that in America too, but that’s for another discussion.  I learned other languages like VB, VBScript, JavaScript, C++, Java, SQL, KiXtart, and onto XML, HTML, XSLT, CSS, PHP, ASP, VB.NET, ASP.NET, PowerShell, and whatever.  Who really cares.  I never let go of any of them and more often than I ever expected: I was hit with a task that required me to put other hats on and go in to fight the fire.

If you’ve been programming for more than ten years, think back on what languages you have ever used in the past.  Ever used.  Even played with.  What do you miss about them?  Is it syntactical?  Is it structural?  Is it extensibility?  Is it a nuance?  Or does it just remind you of a really crazy drunken party and someone’s underwear hanging from your car antenna?  Most of us feel like we’re always playing keep-up in order to avoid feeling (or being viewed as) “left behind” with respect to our peers.  It’s really a dumb, self-imposed angst.  Vendors keep pumping the hype to sell the next product line, and we go after the bait like trained fish.

Programmers all have their favorite languages, for whatever reason.  But, ask yourself why you no longer use that language.  What specific things led to you leaving it behind?  Would you want to use it again if the situation called for it?  Why?

Translating Programmer Comments into MBA-speak

"The problem was with the ___ and had to be updated to suit ___"

Translation: The programmer screwed up.  Repeated use of third-person, inanimate narrative comments is usually an evasion tactic.  Never trust them.

"The new system supports ___ and ___"

Translation: We want to go to the training conference for the new system/product out in Vegas, to get some lap dances and gambling out of our system and bring back enough swag to fool you into thinking it was all about the training.

"There was a glitch in the ___, but now it's fine."

Translation: I fucked up and covered my tracks before telling you it was now fixed.

"We can get a discount/deal on ___ if we ___"

Translation: The vendor just blew me and I've drunk the Kool-Aid. He/She and I are now buddies.

"The ___ needs to be recoded to make it more ___"

Translation: I fucked the code up so badly that even I cannot make sense of it anymore.

“We should [never/always] develop our own programs.”

Translation: I never went to school.  I read about technology in the back of a Hustler magazine on the page that weren’t stuck together.

“We had a problem with the backups for that night and couldn’t get a restore for that file you wanted”

Translation:  I was out drinking with the guys and forgot to put a tape in the backup rig.  Or I was busy in the bathroom stall looking at porn sites on the iPhone and forgot to run the backup that night.  Take your pick.

“I don’t think we can save your setup.  We’ll have to slick and reload your computer”

Translation: We have no idea whatsoever what we’re doing, and don’t have a clue as to how to solve this problem without looking like a pack of oafish idiot bastards wandering aimlessly in a cow pasture at 1:00 am.

“We should replace all our Windows servers with OSX Server and switch everyone to Macs.  Our law firm would kick ass, sir.”

Translation:  Not only have I never sat in a CS class.  I don’t know what CS stands for.  I can’t even spell CS.  In fact, I don’t know what spelling is.  I’m a complete idiot dumbass bastard with a fork in one eye and a jar of vaseline in the other.  My other job is licking restroom floors at the bus station.

“There’s no way to make your Macbook talk to our Windows network.  You’ll have to get a [Dell/HP/Toshiba/Sony/whatever], sir.”

Translation: I’m so ridiculously and helplessly stupid, you should lace up some ice climbing boots and kick me in the face about 450 times, or until you hear a fat lady singing.  Afterwards, sprinkle meat tenderizer on my remains and toss me into the tiger den at the zoo.

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.

Ah, I Love the Smell of (mapcar) in the Morning...

I still consider LISP my favorite programming language.  PHP and KixTart are a close second.  The distinction between a "programming language" and a "scripting language" is getting murkier all the time.  (warning: I've had two beers already.  i'm off work until next week)

For all the nay-sayers of LISP, f-u.  Rather:  (defun f-you (princ "that's correct."))

The problem I have with so-called modern languages is that they're designed to be functional first, exploratory second.  That's a buzzkill for making it fun to program.  Anyone out there that remembers SmallTalk or AutoLISP knows what I'm talking about.  If the earliest language you can recall clearly is C++, well, I pity you.  Bjarn called it "C with classes" but I would call it "C with garbage and 400 cooks in the kitchen".  A leap above Pascal without a doubt, but messier than Java or C#.  Oh whatever.  On to the blabbering....

This article on problems with UML is very interesting.  I haven't enjoyed reading a geeky, nerdy, sticky, messy, techy article like that in quite a while.  The mapping of abstract flows and structures to specific domain layers of an architecture is indeed intricate stuff.  The problem is compounded by specific domains (languages) as well as platforms (physical, logical, and virtual), so you can't fault the intent or ideal UML is aiming for.  It's noble.  Damn.  I said "noble" in a sentence.  Heh.  That's what happens when you follow up a Sam Adams' Cherry Wheat Ale with a Hoegaarden Ale.  My mind has wandered indeed.  Ok, where was I...

His third (major) paragraph makes sense to me.  However, the fourth has a slight problem.  For one, UML, like SOAP and other modern idioms, has too many masters and too many servants.  Forget 400 cooks in the kitchen.  The cook now has 400 kitchens.  It's a slightly less broken version of what Ada was trying to accomplish (another failed grand master plan).  For the non-programmers out there, look up Esperanto.

The basic problem is that MBA's continue to walk off of their red-eye flights fresh with ideas from the magazine pocket in front of them.  Usually something like seeking a way to make programmers, network administrators, and systems admins obsolete.  You know, the whole "can't we make computers smart enough to setup themselves and keep themselves running?"  Yes.  They can. They're called Macs, but they suck for business objectives, unless you don't need to run many non-Windows-only applications to get work done.  For everything else they're great.  But I digress.  I'm sure that will incite flames from the Mac fanatics, but I'll say it here:  Windows sucks too.  There.  Have a nice day.

What I miss most about LISP is the flexibility.  It has (had) one of the lowest on-ramps to learning I ever saw.  That is, unless you were already poisoned by a traditional procedural or OO language.   The notion of list constructs, and parsing/tokenizing as first-class operations is weird to those people.  Ascertions like (mapcar) (apply) and (cons), not to mention the plethora of (car/cdr/cadr/caddr/cadar/caadr/cadddr/etc) list plucking functions and the ubiquitous lambda expressions, all are what make LISP like a 40-ton Lego constructor kit.  The kind without any instructions, just a huge box with bins for various blocks by color, shape and type.  That's what I loved about it.  I could explore it and find ways to build new things which never seemed to suffer from the language itself getting in the way.

Alas, it was mired down in geo-political committee goo and fell behind in public favor compared to other languages.  It had everything in place to do what Java was designed to do:  be portable.   It already had a JIT compiler and a mature foundation.  What it lacked was a robust UI API.  Autodesk bolted one on for DCL dialog development but gave up on that too.  Then SharpLISP took another stab at that but the timing was wrong and it fell off the wagon.  The good ole days were pretty cool.  Software used to be exciting and fun to discover.  It seems to have become a chore now.

Another Segment of the John Walker Interview

Kean Walmsley has posted part 2 of a 4-part interview with Autodesk co-founder John Walker. This one dives a bit deeper into the reasons behind, the and history of, extending AutoCAD with a programmable interface. I couldn't agree more with John's comments on programming language advantages and the references to things having been done before and simply re-discovered. How true!

I've always preferred LISP over other programming languages. It's just a fun language to work with and arguably one of the most flexible to work with. What other languages allow you, no, compel you, to develop a program that can reprogram itself at runtime? I'm not talking about conditional branching, but actual, true dynamic self-definition. Code that writes itself as needed. If you have ever worked with LISP for more than a few months you know what I'm talking about. Combining (defun) with (mapcar), (lambda) and (apply) and a pinch of recursion, and BOOM you have some really incredible stuff to leverage.

I was learning LISP, and XLISP while in college, but AutoLISP really injected me with a dose of enthusiasm because it was the first time I was able to combine raw programming with graphical output. At the same time, I was having to develop projects at school in C++ and Java, but those felt like a dull chore. Employee database tables with "employee" objects and class templates. Objects are definitely cool, but LISP is cooler (to me anyway). The list paradigm sort of compares to working with nothing but class templates, but with less effort and constraint. Oh well. There's nothing for a LISP programmer around here anymore. Even my old book fell into obscurity, but hey, PHP is cool (and still free), as are true scripting tools like VBscript, and KixTart. PowerShell to me feels like C# (translation: "work", not "fun"). Maybe when it matures and becomes more pervasive I will see it differently. But right now, you can't use it to do login scripts or web development as easy as you can with VBscript (still the crux of ASP) or KixTart, or even BAT/CMD. It's definitely more powerful, but comes with a complexity price tag.

I digressed horribly here. Sorry. :(