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