If you’re a power user or CAD Manager transitioning from AutoCAD to BricsCAD, one of the things you’ll like is that almost all of your LISP routines will just work. That’s not an statement that can be made about various Autodesk products that bear the AutoCAD name, such as AutoCAD 360, AutoCAD LT and AutoCAD for Mac.
It’s not just simple old AutoLISP code that runs in BricsCAD, but complex dialog routines that use DCL, and Visual LISP stuff that uses ActiveX. Yes, even on the Mac and Linux platforms. Some DOSLib functions are built in and the rest can be loaded, as with AutoCAD. Even OpenDCL is supported. It’s a quite astonishingly high level of compatibility.
But it’s not 100%. There are minor incompatibilities, system variable and command-line differences that cause problems in a handful of cases. It’s often possible to work around these and still retain the same code that works in both AutoCAD and BricsCAD. Reporting LISP bugs and incompatibilities to Bricsys generally gets them fixed super-quick.
Also super-quick is the speed at which your code will run. It’s immediately noticeable when running any LISP code that needs to do a bit of processing that it just gets done faster in BricsCAD than AutoCAD. Fast enough to extract the following comment from one of my AutoCAD users trying out a linework cleanup routine in BricsCAD:
Wow.
User impressions are one thing, but how about measurements? Today, I had a support job to do that involved running one of my LISP routines. I ran it on both AutoCAD 2017 and BricsCAD V17 on the same PC. AutoCAD took 2970 seconds (about 49 minutes), BricsCAD 1030 seconds (about 17 minutes). Over half an hour saved on one operation. That’s 2.88 times faster, which is consistent with my previous observations with a variety of routines.
Upshot: if you’re doing work where there’s a lot of LISP processing going on, switching to BricsCAD is going to save you a shedload of time.
There is a downside to BricsCAD’s LISP, and it’s a big one; no VLIDE. No equivalent, either. There are various programming editors around that can help with editing code, but no substitute for integrated debugging. It means if you’re a power user, CAD Manager, developer or support person, you’re probably going to have to keep one working copy of AutoCAD around even after you’ve completed the transition to BricsCAD.
Because VLIDE has been in maintenance mode for over 15 years it remains virtually unchanged year after year (including ancient bugs). So it doesn’t matter that much which AutoCAD release you have hanging around. Assuming you’re a perpetual license holder, when you drop the maintenance contract on one of your AutoCAD licenses, you’re entitled to keep using the software as long as you wish, albeit only the current release at the time the contract ends. How long the software will keep working is another matter, depending as it does on factors not entirely within your control.
This is an imperfect solution. Even keeping a copy of AutoCAD around won’t help much if you’re debugging a problem caused by something specific to BricsCAD. Filling the VLIDE hole is something Bricsys needs to work on.