Shiny New AutoCAD, Same Old VLISP

I'm beyond the point of crying over the demise of Visual LISP.  A once-mighty development platform with an impressive following (and one-time unrivaled volume-king of content), now relegated to bleeding out on the scrap heap of soon-to-be forgotten languages.

When John Walker chose LISP as the core extensible language for AutoCAD, he did so on the basis of its inherent dynamic polymorphic nature.  Recursion and chameleon-like characteristics made it as fluid and flexible as a the T2 walking through the mental hospital metal bar gate (without the pistol, of course).

What Autodesk is ignoring is potential. There is and always has been potential within the Visual LISP world to grow the language as a standalone platform. It could be used for so much more than CAD purposes. Even DCL could join in on the ride beyond the walls of Fort AutoCAD.

Once unfamiliar programmers got used to working with lists and functions like mapcar, apply and lambda, who knows where it could lead?

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?

What if AutoLISP were Unleashed?

Way back when, (a completely meaningless phrase of course), Autodesk had the audacity to introduce a radically new concept into a software product: Extensive Programmability.  They did that using DIESEL, AutoLISP, and the MNU file.  They could have just dropped a “here-you-go-take-it-as-is” product without any meaningful customization features or tools, but they didn’t.  Autodesk instead decided to empower their customers, enabling them to extend and reshape their products to suit their own needs.  This simple decision had a profound impact on their customer base, as well as product sales. Indeed, it created an entire community and industry that otherwise wouldn’t have existed.

I’ll spare you the regurgitated history stuff, you can look that up online.

There is something that has been ticking around in the back of my head for a long time:

   What if Autodesk had ported the AutoLISP platform outside of AutoCAD?

Keep in mind that this was in the 1980’s, and Java didn’t yet exist, neither did .NET.  The most popular “cross-platform” scripting toolset at the time was Perl (and ActivePerl). Most AutoLISP programmers I knew between 1988 and 1995 were always wishing for more OS features, many of which were made possible through third-party tools like Robert McNeel’s DOSlib. There were also many that begged for a better dialog programming toolset, which was later made possible by OpenDCL, another third-party product.

Autodesk however had other desires.  They were starting to drink the Microsoft Kool-Aid, and decided to drop LISP at the altar and run off to Vegas with VBA.  After all, she was hotter and wore thongs and high heels at the time.  Then when VBA put on a few pounds and started wearing sweats around the house without make-up, they ran off to Bangkok with the svelte .NET, along with a crate of condoms and a case of Bud.  LISP was left in the alley, panhandling for spare change, needle tracks were starting to show on her arms.  AutoLISP was swapped with Visual LISP, which remains to this day, but is ignored in much the same way as Middle Class workers are in America.  The world of AutoCAD customization now belongs to ObjectARX, or so we're told.

I won't go into the flaws with this mindset of ObjectARX over LISP, but I know that I'm not alone in feeling it's a huge mistake to ignore Visual LISP they way it's been ignored thus far.

But what if?  What if not only had they continued to breathe life into Visual LISP, but they had made it possible to run AutoLISP code from a dedicated script engine from outside AutoCAD?  I'm talking about much like was/is possible using ActivePerl, KiXtart, CMD or VBScript.  Imagine the power that thing could’ve unleashed for LISP programmers.  I can only imagine the potential it could have had for much more than batch processing of DWG files.  Granted, the constraints of AutoLISP capabilities would have required a significant amount of expansion, which was in short supply after the acquisition of Vital LISP® was renamed Visual LISP®.  It was as if they had adopted a 3 year old child who spoke an unknown language, so they left him alone in the toy room with the dog, tossing food on the floor, and quickly shutting the door.

Imagine the potential of combining the file system features of DOSlib with the dialog building features of OpenDCL with powerful intrinsic functions like (mapcar), (apply) and (lambda).  In case you need a poke in the brain: Remember that LISP is built for recursion and that file systems are perfect for recursive operations.  Not just file systems either, but any data source.

The basic tenants were fairly unimpressive: a script engine that is ported to various “present day” platforms (Windows, OSX, Linux) which executes the same code the same way. Gee.  That sounds a bit like Java.  That also sounds like .NET, sort of, maybe more like Project Mono.  But those two platforms weren't even concepts in 1990.  In any case, you get the idea.  That is, if you’re still awake and reading this far.  I’m guessing few of you have read this far without falling asleep or moving on to something more interesting.

Alas, this idea was never on the table, officially, so it never could’ve become reality.  Never mind that there haven't been any meaningful updates to VLIDE or Visual LISP in years.  I'm still a pie-in-the-sky person, and I'm often given to dream crazy things.

The Visual LISP Developer's Bible, 2011 Edition

I would have posted this sooner, but I'm still barely out of bed with the Flu and bronchitis.  I hate Winter.  This was actually available a day ago but I've been medicated and sleeping.  I'm going back to bed now.  I hope you like this.  I put a lot of work into it and Phill Ash put a lot of editing/proofing time in as well.

The Kindle e-Book: http://www.amazon.com/dp/B004I43BFK

The Web Site: https://sites.google.com/site/visuallispbible/home

B-b-b-b-b-books

My book on Visual LISP Development, aptly named "The Visual LISP Developer's Bible" has been submitted to Amazon's Self-Publishing program for approval. If approved, it will be available for eBook download at the ridiculously cheap price of $4.99 (USD). If you care to prevent the starvation of my toothless and shoeless children, you will consider skipping one Starbucks to buy this outdated book. My busload of poor children will thank you from the bottom of their empty stomachs.


Now for some even really gooder news! I am writing another book! Yes. It's true. They allow me to touch a keyboard still. What's it on, you ask? Why, it's going to be about deploying and managing Autodesk software products in a Windows network environment and using things like scripting, and Configuration Manager and dozens of trips to Starbucks and the nearby bars. It will be loads of action-packed excitement and adventure. Stay tuned!

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?

Visual LISP (and AutoLISP) is Officially Dead

I'm sure some of you will disagree, but it's true.  Autodesk will never admit it, but it's true.  Ever since they fell in love with VBA, and got dumped in an alley by VSA, and then thought it would somehow catch on with the masses of casual programmers (those of us trying to get a job done, and programming code JUST ENOUGH to make the job easier and quicker).  Even though there are still (last I checked) some chores that ObjectARX (.NET) still can't do as well, or as "elegantly" as LISP, they're not going on a second date.  She's been dumped.  Bon voyage LISP.  It was a wonderful journey.  I will miss you.

PS.  The Visual LISP Developer's Bible project is officially comatose with no brain activity.

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…