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.
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...
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.
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.
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.
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
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.
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.
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.
My brother's electrical company needed hundreds of Schaltpläne (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.
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.
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.
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.
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.
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.
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)
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 (Schütz) would automatically generate its coil
in the control circuit. Code writing code, classic LISP.
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.
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.
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
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)...
> 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.
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...
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.
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.
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.
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
fixed it, thx for the notice
I have a lot of interest in this space for infrastructure design. Thanks for sharing.
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.
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.
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.
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.
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.
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.
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.
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.
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
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 (Schütz) would automatically generate its coil in the control circuit. Code writing code, classic LISP.
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
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.
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.
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
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...
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)...
> 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.)
This website is a mess on mobile. Cool concept though!
You are right, i did not target mobile, but will fix some