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?
No comments:
Post a Comment