This is a duplicate of the Blog posted on the Bricsys Blog Site…. https://blog.bricsys.com/insights-stories/using-lisp-today-part-1/
LISP: What is old is still very new
Welcome to Part 1 of my first post on the Bricsys Blog! I’ll be writing about LISP programming and transitioning your existing code into the BricsCAD environment. I’ll review implementation, differences from other environments, tips & tricks, and other topic requests from our readers. Or, if you haven’t started looking at LISP, maybe I can give a little encouragement and let you know that LISP is alive and well. It is definitely a language worth considering for BricsCAD customization.
First, let me state that I’ve written a couple hundred thousand lines of LISP over the last few decades. But I still would not call myself an expert. I don’t know all of the vl-commands, or some of the more “advanced” functions. Please forgive me if I present a method that isn’t the most efficient, or if I suggest a paragraph of code that could be replaced by a single function. Chances are good that I had no idea that the “better” function existed! I still stumble across “new” (to me) commands on a regular basis. When I do, I often wonder how much time that newly-discovered function might have saved me.
A while back I was questioned by a client about my continued coding in LISP. I actually thought it may have become a skill set that had become obsolete. Think about (manual) drafting skills and mastery of the Vemco Drafting Machine – now, those are obsolete! But when I looked at my customer’s real needs, I found more and more reasons to update or develop new LISP functions. I think that it will be fun to share some of these concepts with you to help you get started.
Is LISP the Rosetta Stone of CAD customization?
The name “LISP” comes from the words “List Processing”. Data is stored in .dwg files as lists, and LISP reads, writes, changes and stores that data. Best of all, this code is platform independent. It’s efficient, small and flexible. I prefer the simplicity of developing code in a non-compiled language. While LISP code does not need to be compiled, you can encrypt your programs to protect your source code. Many programs that I wrote twenty years ago on “vintage” hardware/software/OSes still work today in current versions of BricsCAD with little or no modifications.
Recently, I was asked to solve a migration issue for a client who was transitioning from AutoCAD™ 2014 to 2016. This company’s standard CAD setup included over 400 program files with 123,000 lines of LISP code, with around 4,000 functions defined. After a bit of research, I discovered that the primary issue was related to a couple of (compiled) ARX applications that were not compatible with AutoCAD™ 2016. Their LISP code, much of which was written in the late 90s, ran perfectly.
When I’m asked to consult on CAD standards migration, I first determine how much of a company’s workflow is dependent on 3rd party tools. Then, I check to see if their tools need specific software versions or platforms. Often, the only issues revolve around hard-coded folder paths that need to be updated.
Why use LISP for custom CAD programs?
So, what are some reasons to create custom programs in your CAD environment? Typically, I write code to improve process or workflow automation, relating to specific CAD entities or CAD standards. Routines can be as simple as a few lines of code. These functions can perform layer manipulations, change entity properties, automate drawing and XREF relationships, or help standardize plotting and publishing workflows.
Or, these routines can be as complex as a parameter-driven design process, or an application to automate database access. As I mentioned earlier, a key benefit to using LISP is simply the small size and great efficiency of the language in a CAD environment. In the example we’ll explore in Part 2 of this post, the LISP code to do simple geometry manipulation (move and rotate) can be a fraction of what one might have to write in a compiled language ( .NET, C, C++, et al).
For the sake of page space, I’m not including a .NET example here. But, if you really want to see what I’m talking about, just Google: “Create a move command with .NET API” and you’ll see a few examples. These compiled languages often require hundreds to thousands of lines of code to create the graphical behaviors and intuitive interfaces that users expect in a day-to-day CAD environment.
(This post will be continued in Part 2)