BricsCAD’s LISP kicks sand in the face of AutoCAD’s

BricsCAD’s LISP kicks sand in the face of AutoCAD’s

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.

10 Comments

  1. Note that while you cannot debug lisp in bcad, you can compile several lisps to .des format, which is like compiling to .vlx with acad. Then your code is protected. Only downside is there is no “separate namespace” compile option, so you need to use global vars with names different than other lisps so they don’t step on each other’s toes. I prefix with prog name anyway like (setq myprog:counter 0) or whatever. I love that the descoder app which does the compiling to .des goes so fast, I can open and run it and be done before my lisp project finishes compiling. Uses same .prj file as vlide too.

  2. Woah! I hadn’t thought to do a direct speed comparison between the two programs. I grabbed a random command in my software that takes a little bit of time.

    BricsCAD: 19.5 seconds, AutoCAD 2007: 21.8 seconds, AutoCAD 2017: 28.9 seconds.

    I didn’t realize BricsCAD was so much faster, and I had kind of forgotten how much AutoCAD itself has slowed down over the years.

    1. That would probably be the “not 100%” comment above. I’ve had to make a few adjustments here and there to a small portion of my routines.

      Without knowing the details it’s hard to say exactly what’s going on in your case. I suggest you log a support call with Bricsys; if it’s a genuine bug or incompatibility there’s a good chance of getting it fixed.

  3. Tom Berger

    VLIDE for BricsCAD is on the way!

    Torsten Moses, the developer of the famous Lisp in BricsCAD, is working on a VLIDE including a powerful debugger. I already have a beta version here, and it looks good!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.