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...
If you look at a map of the fiber-optic network in the US, my parents spent most of the 90s surveying the portion along the Gulf coast from Texas to Florida and up the Atlantic coast to New England for Sprint, MCI, Level 3, and other companies that no longer exist and AutoLISP was used to generate most of their drawings.
From what I can remember, we made a spreadsheet template that captured the title block information and a list of bearings and distances with some optional columns for field notes, landmarks/monuments, elevations and other measurements, etc. and I wrote some AutoLISP code that would generate an overview drawing and a set of scale drawings for the route. It figured out the bounds for each segment based on the scale and drawing size and then drew the route like a turtle and added the various callouts and a consistent title block and legend. There was also some ability to draw details about the railroad/pipeline whose right of way was being used, but I don't remember exactly how it worked.
My mom (secretarially trained typist, self-taught Lotus/Excel wiz, former drafting assistant at an RBOC) would enter everything into the template and use it to generate basis drawings which they might then tweak and finalize by hand. It dramatically reduced the amount of time they spent creating drawings to the point they could usually finish the drawings for a week of surveying in a couple of hours. I like to think of it as my small contribution to the Internet.
I was in high school at the time and taught myself AutoLISP from some combination of in-app docs/help and mall bookstore fare. Now I desperately want to go dig through floppy disks at my parents' place to see if any remnants remain to look back at how younger me did everything. It was the first truly useful software that I ever wrote, and in hindsight, might've planted the brainworm that led me to Clojure decades later :)
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.
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.
In 1990 I used AutoLISP to setup a tool that the state legislature would use for redistricting after the census. The AutoLISP let them interactively assign counties to districts while seeing the voter numbers and then export it to a CSV file which was read into a database. They could also export from that database back into AutoCAD using AutoLISP.
Redistricting with AutoLISP - that's a use case I never imagined. Interactive county assignment with live voter counts, bidirectional CSV sync. Democracy infrastructure in a CAD macro.
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
And I had been looking at it on mobile, which might have been why I was having an issue with the site; now that I'm looking at the site on a desktop browser it looks much better.
I wrote a ton of AutoLISP back in the day to do similar things to generate well logs for environmental and geotechnical reports. Fun stuff.
In 1990 I went to work at Autodesk and got to work on all kinds of stuff over the next decade -- AutoLISP was the bridge that got me into tech as a profession over the geology field work I was doing. It's been a wild ride.
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.
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.
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
Ah, Autolisp. Based on an early, early version of XLisp, it's zombie software: not quite alive—Autodesk really wants you to use its COM and .NET integration to program AutoCAD—nor can it truly die. It was also the first Lisp I ever programmed, and back in the mid-90s there was a trend of putting a Lisp, or Tcl, into all the things (Emacs, GIMP, frickin' Abuse...) and Autolisp had prepared me for that world rather well.
That mid-90s trend of embedding Lisp/Tcl everywhere was special. Everyone understood: give users a real language, not just config files. Emacs, GIMP, Abuse, AutoCAD - all bet on "let users program it." Now we have YAML and JSON configs. Progress?
Part of why I built this: if AutoLISP becomes truly undead inside AutoCAD, at least the workflow and playground can live on independently in the browser.
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.
Huge thanks to everyone in this thread — the stories, pointers, and critique were genuinely useful (and motivating). Quick update: we pushed a big round of UI fixes and the site is now properly usable on mobile. Also, I compiled Betz’s original XLISP (C) to WASM and hooked it up as a side-by-side benchmark, and the first external PR just landed: KiCad export is now in (symbols + footprints), so the same template workflow can emit .kicad_sym / .kicad_mod. Really grateful for the help here.
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.
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.
I cargo culted my way into AutoLISP in the R12 era knowing nothing about lisp or funtional programming (BASIC and a tiny bit of Pascal was all I'd done by then). Just using notepad without any assists like highlighting matching parentheses and no deeper theoretical knowledge was tough, but I could see vague outlines of a world of mathematical elegance just out of my grasp.
"Vague outlines of mathematical elegance just out of grasp" - that's exactly it. Notepad, no paren matching, just counting brackets by hand. The elegance was there, we just couldn't quite see it yet.
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.
You may be already aware with this, but if not, Walker actually did write a small Forth (ATLAST -- https://www.fourmilab.ch/atlast/) which was used for (I think) DXFTOOL (a file converter).
It was later used by a small computer graphics studio in Tennessee for a blue/green screen matting utility and a fast roto-paint program.
Very interesting, even if tools like ATLAST had been available for free back then, AutoLISP would have won. HP-41CV programming had already wired my brain for stack thinking, and LISP felt like the natural next step. Forth was too raw, LISP had just enough structure.
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...
If you look at a map of the fiber-optic network in the US, my parents spent most of the 90s surveying the portion along the Gulf coast from Texas to Florida and up the Atlantic coast to New England for Sprint, MCI, Level 3, and other companies that no longer exist and AutoLISP was used to generate most of their drawings.
From what I can remember, we made a spreadsheet template that captured the title block information and a list of bearings and distances with some optional columns for field notes, landmarks/monuments, elevations and other measurements, etc. and I wrote some AutoLISP code that would generate an overview drawing and a set of scale drawings for the route. It figured out the bounds for each segment based on the scale and drawing size and then drew the route like a turtle and added the various callouts and a consistent title block and legend. There was also some ability to draw details about the railroad/pipeline whose right of way was being used, but I don't remember exactly how it worked.
My mom (secretarially trained typist, self-taught Lotus/Excel wiz, former drafting assistant at an RBOC) would enter everything into the template and use it to generate basis drawings which they might then tweak and finalize by hand. It dramatically reduced the amount of time they spent creating drawings to the point they could usually finish the drawings for a week of surveying in a couple of hours. I like to think of it as my small contribution to the Internet.
I was in high school at the time and taught myself AutoLISP from some combination of in-app docs/help and mall bookstore fare. Now I desperately want to go dig through floppy disks at my parents' place to see if any remnants remain to look back at how younger me did everything. It was the first truly useful software that I ever wrote, and in hindsight, might've planted the brainworm that led me to Clojure decades later :)
thx for sharing, really interesting
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.
Nice to hear such interesting stories
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.
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.
Nice project.
In 1990 I used AutoLISP to setup a tool that the state legislature would use for redistricting after the census. The AutoLISP let them interactively assign counties to districts while seeing the voter numbers and then export it to a CSV file which was read into a database. They could also export from that database back into AutoCAD using AutoLISP.
Redistricting with AutoLISP - that's a use case I never imagined. Interactive county assignment with live voter counts, bidirectional CSV sync. Democracy infrastructure in a CAD macro.
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
Thanks, the repo link works now!
And I had been looking at it on mobile, which might have been why I was having an issue with the site; now that I'm looking at the site on a desktop browser it looks much better.
I wrote a ton of AutoLISP back in the day to do similar things to generate well logs for environmental and geotechnical reports. Fun stuff.
In 1990 I went to work at Autodesk and got to work on all kinds of stuff over the next decade -- AutoLISP was the bridge that got me into tech as a profession over the geology field work I was doing. It's been a wild ride.
I have a lot of interest in this space for infrastructure design. Thanks for sharing.
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.
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
Ah, Autolisp. Based on an early, early version of XLisp, it's zombie software: not quite alive—Autodesk really wants you to use its COM and .NET integration to program AutoCAD—nor can it truly die. It was also the first Lisp I ever programmed, and back in the mid-90s there was a trend of putting a Lisp, or Tcl, into all the things (Emacs, GIMP, frickin' Abuse...) and Autolisp had prepared me for that world rather well.
That mid-90s trend of embedding Lisp/Tcl everywhere was special. Everyone understood: give users a real language, not just config files. Emacs, GIMP, Abuse, AutoCAD - all bet on "let users program it." Now we have YAML and JSON configs. Progress? Part of why I built this: if AutoLISP becomes truly undead inside AutoCAD, at least the workflow and playground can live on independently in the browser.
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.
Huge thanks to everyone in this thread — the stories, pointers, and critique were genuinely useful (and motivating). Quick update: we pushed a big round of UI fixes and the site is now properly usable on mobile. Also, I compiled Betz’s original XLISP (C) to WASM and hooked it up as a side-by-side benchmark, and the first external PR just landed: KiCad export is now in (symbols + footprints), so the same template workflow can emit .kicad_sym / .kicad_mod. Really grateful for the help here.
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.
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.
I cargo culted my way into AutoLISP in the R12 era knowing nothing about lisp or funtional programming (BASIC and a tiny bit of Pascal was all I'd done by then). Just using notepad without any assists like highlighting matching parentheses and no deeper theoretical knowledge was tough, but I could see vague outlines of a world of mathematical elegance just out of my grasp.
"Vague outlines of mathematical elegance just out of grasp" - that's exactly it. Notepad, no paren matching, just counting brackets by hand. The elegance was there, we just couldn't quite see it yet.
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.)
You may be already aware with this, but if not, Walker actually did write a small Forth (ATLAST -- https://www.fourmilab.ch/atlast/) which was used for (I think) DXFTOOL (a file converter).
It was later used by a small computer graphics studio in Tennessee for a blue/green screen matting utility and a fast roto-paint program.
Very interesting, even if tools like ATLAST had been available for free back then, AutoLISP would have won. HP-41CV programming had already wired my brain for stack thinking, and LISP felt like the natural next step. Forth was too raw, LISP had just enough structure.
AutoLISP programming is the only LISP programming I’ve ever done. Memories.
This website is a mess on mobile. Cool concept though!
I fixed what is fixable for this purpose, and thx it helped to have it overall better!
You are right, i did not target mobile, but will fix some