[HN Gopher] Show HN: AutoLISP interpreter in Rust/WASM - a CAD w...
___________________________________________________________________
Show HN: AutoLISP interpreter in Rust/WASM - a CAD workflow
invented 33 yrs ago
Author : holg
Score : 100 points
Date : 2025-12-26 15:56 UTC (7 hours ago)
(HTM) web link (acadlisp.de)
(TXT) w3m dump (acadlisp.de)
| holg wrote:
| In the early 90s I wrote AutoLISP code for AutoCAD 9/10 that
| enabled a CSV - template - parametric drawing workflow. You could
| define components in spreadsheets, feed them through templates,
| and generate complete technical drawings automatically.
|
| I've never seen anyone else use this approach. Now I've built an
| interpreter in Rust/WASM so it can run in the browser - partly
| nostalgia, partly preservation before this knowledge disappears
| entirely.
|
| The lisp/ folder contains some LSP files from that era, others i
| recreated from memory.
|
| Repo: https://github.com/holg/acadlisp/
|
| What kind of drawings were you generating? Electrical schematics,
| mechanical parts, architecture? We also have some playground, to
| toy around with LISP and some function generator, to demonstrate
| Lisp usage for math...
| lambda wrote:
| I get a 404 for that repo; is it private?
|
| Also, the page you link to in the original post is in German;
| it might be nice to have an English page for the mostly English
| speaking audience here on HN
| holg wrote:
| fixed it, thx for the notice
| stocksinsmocks wrote:
| I have a lot of interest in this space for infrastructure
| design. Thanks for sharing.
| 51Cards wrote:
| We were on the same page. I also built something similar for a
| Conveyor company here in Canada in the early 90's. We
| parameterized all their tech drawings (or at least the initial
| versions) from their component libraries. Was a great project.
| Not sure how long they used it, they eventually acquired the
| resources to support it internally (I was an independent
| AutoLISP contractor). Good times back then. I haven't done
| AutoLISP in years now but great to see it's still around.
| holg wrote:
| Ha, so I wasn't alone! Conveyors are a perfect fit -
| standardized components, parametric variations. The pattern
| was obvious once you saw it. Good to know it worked for you
| too.
| robomartin wrote:
| AutoLISP is how I learned LISP back in the 80's. I probably
| used it for about twenty years. I wrote a massive amount of
| code to automate ACAD use in three areas: Schematic Capture,
| PCB Layout and Broadcast Facility design and Construction.
|
| The first two were complimentary. Before that I was laying out
| PCB's by hand using (who can remember?) Vector tools and Xacto
| knives. Switching to ACAD with AutoLISP-based automation was a
| game changer.
|
| Broadcast facilities are not very different from data centers,
| in the sense that you have loads of racks filled with
| equipment. I would say that one of the key differences was that
| the equipment was not as homogenous as it might be in data
| centers. Back then I was very involved in some massive studio
| projects, both in terms of facility design (not the
| architecture, the design and installation of the technology)
| and custom software/hardware for the same industry. Once again,
| in the early days all wiring diagrams were being done the old
| fashion way, with pencil and D-size paper on a drawing table.
|
| I started with ACAD version 1.0 or 1.1, I can't remember. This
| ran on an 8086 CPM computer build on an S-100 frame. It
| actually had an 8087 math coprocessor board and another board
| with 512K (you read that right) of RAM to mount as a RAM disk.
| The computer had 64K of RAM. So, yeah, early ACAD ran on a
| system with 64K of RAM.
|
| The studio AutoLISP software was the most extensive. It took
| advantage of 3D features to do such things route cables between
| equipment in different racks and rooms as well as compute the
| required cable lengths. It would generate cable cut lists and
| labels for the wiring crew, etc.
|
| This also included managing a symbol library for these designs,
| much as a tool like KiCAD or Altium (which has now officially
| gone to shit!) manages both schematic symbol and PCB footprints
| for ECAD work. The equipment definitions included such things
| as input/output signal types, required cable type, connector
| types, wiring schematic and rack mount models (for laying out
| where in the racks each device would be installed).
|
| This is work that I evolved over years as we designed and built
| many installations across the country. It was a valuable
| internal tool with competitive advantages. We left that
| industry behind a very long time ago, but I remember that time
| fondly. Technology was evolving at breakneck speed and there
| were incredible opportunities to develop innovative solutions
| across the entire technology stack, from embedded all the way
| up to custom equipment.
| holg wrote:
| This is beautiful. Schematic capture, PCB layout, broadcast
| facilities - and 3D cable routing with auto-generated cut
| lists and labels. That's the workflow taken to its full
| potential. 64K RAM, 8086 with math coprocessor, ACAD 1.0.
| Memory was such a pain back then. I eventually got a Quadra
| 700 (68MB) with A/UX - Unix on a Mac felt like the future.
| Fun fact: we got Betz's original XLISP (C) running in WASM
| for a benchmark. It destroys my Rust version. But speed was
| never the point - the CAD workflow was. And yours proves the
| pattern scaled far beyond what I did with electrical
| schematics.
| robomartin wrote:
| This is what the facility design wiring diagrams looked
| like:
|
| https://imgur.com/a/niXkSt7
|
| It shows that per-connector metadata that was added to each
| equipment symbol. The metadata allowed AutoLISP to do some
| really cool and intelligent things.
|
| The PCB layout tool had interesting constraints. One of the
| issues was that pad graphics took up way too much memory.
| So, what I had to do, was to layout PCB's using a symbol
| that consisted of two lines forming an X instead of real
| pads. The symbol name encoded the diameter, hole size, etc.
|
| When the layout was done, I had to unload a bunch of
| modules and then run an AutoLISP routine that would find
| and replace all "PAD_NNNN_X" symbols with real "PAD_NNNN"
| symbols before plotting.
|
| Once ACAD migrated to Windows this was no longer an issue.
| Of course, by that time, accessible ECAD tools were around.
| I think my last ACAD schematic and layout was somewhere
| around 1993. I just didn't have the money to invest in ECAD
| tools of the era, so my ACAD tool served a purpose.
| mickdarling wrote:
| Ah, AutoLisp, that brings back the memories.
|
| I can tell you that a good number of the design drawings for
| the higher floors in the Venetian resort in Las Vegas were
| assembled with AutoLisp scripts. The scripts I created grabbed
| components from other drawings that were already made to
| assemble a first pass set of drawings for floors that hadn't
| been fully designed yet, since the floors all had components of
| other floors.
|
| They were still in the design process for the upper floors,
| while the lower floors had already been finished and they were
| moving up the building.
| pjmlp wrote:
| AutoCad nowadays uses .NET as well, and thus any CLR enabled
| language, with a MSIL backend.
|
| https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-390A...
| holg wrote:
| sure it does, but Lisp is special, and for those times it was
| very special. I did not want to show how it is done nowadays,
| but how we had done it 33 yrs ago... And now there is the
| emulator as the web-page, this is what i wanted to share
| (everything works as wasm in the browser)...
| Animats wrote:
| > but Lisp is special, and for those times it was very
| special.
|
| It was the only language available at the time suitable for
| embedding. Memory-safe, small interpreter, sane. Alternatives
| were Forth and TRAC, which would have been much worse. Pascal
| would have been better, but it was too hard to squeeze in.
| The program and data had to fit in 640K. The program was
| built as a tree of overlays and code was swapped in, so less
| used code wasn't resident. But it was a cram job.
|
| (I did some AutoCAD ports and drivers.)
| ofrzeta wrote:
| related: "In Version 2.5, AutoLISP allowed access to the DWG
| database. AutoLISP was based on XLISP, a public domain version of
| LISP written by David Betz. Betz later complained that Autodesk
| had failed to acknowledge the source, which the company later
| did." (https://www.shapr3d.com/history-of-cad/autodesk-and-
| autocad)
|
| https://github.com/dbetz/xlisp
| holg wrote:
| Thanks for the link! I didn't know about the XLISP controversy.
|
| My interpreter doesn't aim for full compatibility - just enough
| to run the schematic generation workflow from 1991. The core
| is: defun, setq, car/cdr, recursion, and the (command ...)
| interface to draw entities.
|
| The interesting part was how templates could trigger other
| templates - inserting a contactor (Schutz) would automatically
| generate its coil in the control circuit. Code writing code,
| classic LISP.
| cmrdporcupine wrote:
| I remember using Betz's stuff on my Atari ST in the 80s (and
| then other stuff he did decades later on the Parallax Propeller
| chip, where he is an active community member). XLISP, advsys,
| and his scheme dialect, too.
|
| I always wondered if he got compensated for the stuff he did
| that then got used in AutoCAD.
|
| Sounds like no
| holg wrote:
| Fun idea: I'll try to compile Betz's original XLISP (C) to
| WASM too. Then we can benchmark 1980s C vs 2024 Rust, both
| running in the browser. Will probably be a crappy benchmark,
| but entertaining - and a nice tribute to the source.
| cmrdporcupine wrote:
| I'm betting I could get an agentic tool to convert the
| whole thing (XLISP and/or XSCHEME) to modern Rust or Zig in
| a half a day.
| holg wrote:
| Just the simple interpreter, built in Rust, but yes we
| can also use the real xlisp, it is pure c, so easy to
| handle for emscripten, i built in the Benchmark, the
| original xlisp c in wasm vs the homebrewn interpreter
| buildsjets wrote:
| I had to accomplish pretty much the same exact task circa 1999,
| but in Aldus Pagemaker using Postscript.
|
| My first job out of college was a 6 month contact at a fairly
| small industrial control manufacturer that had been purchased by
| a larger conglomerate. All of their engineering documentation
| needed to be converted to the new company's format.
|
| The old company had devised a scheme whereby a wire harness could
| be completely described by the part number, which encoded the
| wire size, color, length, and termination. The new company wanted
| a detail drawing for each wire, with thousands in the database.
|
| I made a library of reusable glyphs that could be stored in
| Pagemaker layers, and connected with postscript generated lines,
| and a script to iterate through the part number database and
| generate drawings.
| holg wrote:
| Wire harness specs in part numbers - elegant. Same pattern,
| different purpose: you generated final documentation, we
| generated DXF that fed back into CAD workflows. And what's
| running on this page is the same - a real interpreter executing
| AutoLISP against JSON data, outputting valid DXF. Not a
| slideshow, a local data engine with demo data loaded.
| kayo_20211030 wrote:
| Super interesting. Thanks. AutoLisp was both a pain and
| underrated. But, it was perfect for this sort of stuff. Much
| easier than generating the dxf files directly, say using
| postscript ;-). I love the modern recreations and UI.
| holg wrote:
| Thanks! You nailed it - AutoLISP was the right abstraction.
| Direct DXF/PostScript meant entity tables and coordinate
| gymnastics. (command "LINE" p1 p2) just did the thing. What's
| running here: real WASM interpreter executing AutoLISP, not a
| slideshow. SVG native, DXF export (AC1009), all text editable,
| JSON data feed instead of CSV. My brother could open this page
| and start working the same workflow we did in '91 - better
| feed, better output. And Rust is a surprisingly natural fit -
| Lisp's explicit stack discipline maps cleanly onto ownership.
| What Rust enforces, Lisp already wants.
| zenethian wrote:
| This website is a mess on mobile. Cool concept though!
| holg wrote:
| You are right, i did not target mobile, but will fix some
| MontyCarloHall wrote:
| My brother's electrical company needed hundreds of Schaltplane
| (circuit diagrams). Drawing each by hand = 5 hours per
| plan 100 drawings = 500 hours = 12 weeks
| Professional CAD work? Unbezahlbar (unaffordable).
| The secret weapon: AutoLISP A programming language built
| into AutoCAD The Result: 99.5% time saved 100
| drawings: 12 weeks - <1 hour
|
| This is a general pattern of how automation (including the recent
| wave of gen-AI) reshapes the labor landscape. Automation rarely
| replaces jobs wholesale (i.e. very few people get fired because
| their position was "outsourced" to automation). Rather,
| automation lets people who are proficient in Domain A who need
| some work done in Domain B become proficient enough in Domain B
| with sufficient ease that it's cheaper for them to pick up the
| requisite Domain B skills themselves versus hiring a Domain B
| specialist.
| loufe wrote:
| AutoLISP is still my most fluent language, pleasantly surprised
| to see anything in it on HN. There's something fun about its
| idiosyncrasies, but I am genuinely so glad for modern IDEs,
| linters, tooling in just about every other environment. AutoCAD
| has severely neglected it, despite some large businesses built
| exclusively upon it.
| holg wrote:
| Still your most fluent - that says something about how the
| language shaped thinking. The neglect is real; Autodesk clearly
| wants everyone on .NET, but there's a lot of institutional
| knowledge and working code out there that just... works. Part
| of why I built this: preservation. If AutoLISP fades from
| AutoCAD entirely, at least the workflow can live on in the
| browser.
| mlhpdx wrote:
| AutoLISP programming is the only LISP programming I've ever done.
| Memories.
___________________________________________________________________
(page generated 2025-12-26 23:01 UTC)