µcad: New open source programming language that can generate 2D sketches and 3D

📝 Discussion Summary (Click to expand)

The discussion revolves around programmatic CAD tools, primarily comparing a new offering (implied to be $\mu$cad) against established ones like OpenSCAD, and contrasting them with traditional sketch/GUI-based CAD software.

Here are the three most prevalent themes:

1. Programmatic CAD vs. GUI CAD Usability and Learning Curves

Many users express a preference for language-based (programmatic) CAD, often citing the steep, time-consuming learning curve of GUI tools like Fusion 360 or FreeCAD, especially for non-professionals. Conversely, others argue that complex, real-world designs are faster or only possible in established GUI environments due to advanced features and geometry handling.

Support for Programmatic Preference: > "I’m a much more capable of designing useful models by programming than I am in using CAD software. The way I think about the construction of models is much more suited to standard programming techniques." - Normal_gaussian > "For me, I've never done well w/ traditional 3D CAD... I find that I spend most of my time hunting for buttons in the UI... In code, I do have to repeatedly solve little trig or geometry problems... But I always know that I can just spend five minutes with pencil and paper and get it done, whereas switching to fusion means adding an hour or more of work to multiple designs." - alanbernstein
Support for GUI Necessity/Complexity: > "The hard part with 3d part creation isn’t the graphical interface or language, it’s actually describing and translating part requirements to a manufacturable design, weighing material, weight, fit, geometric, and cost tradeoffs." - jwagenet > "I took a course a long time ago in design for manufacturing, and it became abundantly clear that just because you can conceive of an idea doesn't mean that you can build it." - atrettel

2. The Role and Capability of LLMs in Code-Based CAD

The introduction of LLMs capable of generating code has sparked interest and debate regarding whether this technology lowers the barrier to entry for programmatic CAD, although real-world results are mixed.

Optimism regarding LLM-Assisted Design: > "Such languages can be amenable to LLM generation, reducing barriers to entry." - lovemenot > "I’m building a SaaS around this idea. And I managed to do things waaay more complex than that using LLMs." - ponyous
Skepticism/Mixed Results: > "Just yesterday I had an LLM write an openscad module for generating a 2d rounded rectangle. It worked great! I then tried to get it to write a module to extrude a 2d shape into a 3d shape and it failed spectacularly several times before I gave up." - aclindsa > "I finally got it to do what I wanted. But I’m much much faster and if didn’t have some amateur CAD experience, I don’t know I would have ever succeeded." - 2muchcoffeeman

3. Iterative Workflow and Immediate Feedback

The rapid, script-save-re-render feedback loop characteristic of tools like OpenSCAD is highly valued by users of code-based methods, contrasting with the slower workflow often associated with GUI tools for iteration, a feature the discussion notes is crucial for development speed.

Value of Immediate Feedback: > "One of the best things about openscad is the ability to immediately see the results of a code change in the 3D view... Being able to interact like this makes it much quicker and easier to iterate on a design." - aclindsa
Need for Robustness/Iteration in Libraries: > "I've tried the various programmatic CAD options before, and creating initial shapes is relatively easy, but figuring out how to refer to parts of those subsequent shapes - to e.g. modify further, or build from, or connect to other shapes, is really complex and clunky." - mft_

🚀 Project Ideas

Language-Aware Parametric CAD Constraint Solver & Validator

Summary

A tool that acts as an intermediary layer between basic programmatic CAD languages (like OpenSCAD or a custom DSL) and complex constraint systems, helping to translate high-level functional requirements into precise geometry constraints.
Solves the pain point where programmatic CAD excels at structure but fails when complex, real-world manufacturing constraints (fit, tolerance, material tradeoffs) are needed, often requiring heavy math or falling back to proprietary GUI tools like SolidWorks.

Details

Key	Value
Target Audience	Programmatic CAD users (familiar with OpenSCAD/Python geometry) frustrated by manual trigonometry and complex constraint implementation.
Core Feature	An input processor that accepts natural language requirement descriptions ("Hole diameter must be 10mm + 0.1mm tolerance for an interference fit with shaft X") or structured constraints, calculates the necessary geometric parameters (e.g., offset distances, radii), and validates the resulting OpenSCAD/BRL-CAD code against manufacturing rules.
Tech Stack	Frontend: TypeScript/React for UI/Constraint Entry. Backend: Rust/Go for robust geometric calculation and constraint solving (potentially leveraging aspects of existing kernels or dedicated libraries). CI/Compilation: Integration layer for OpenSCAD/CadQuery execution and rendering validation.
Difficulty	High
Monetization	Hobby

Notes

This directly addresses the frustration expressed by users who prefer programming but get bogged down by geometry: "In code, I do have to repeatedly solve little trig or geometry problems" (alanbernstein) and the need for "weighing material, weight, fit, geometric, and cost tradeoffs" (jwagenet).
It bridges the gap between code-based design and professional requirements often handled only by expensive GUI tools.

Interactive Iterative CAD Environment (IICE) Focused on AST Manipulation

Summary

A specialized IDE/Viewer built specifically for code-based CAD tools (like OpenSCAD, µCAD, or CadQuery) that separates the Abstract Syntax Tree (AST) visualization from the final render output.
Provides rapid, context-aware feedback on individual nodes/operations within the code structure, enabling much faster debugging of complex boolean operations and feature interactions than monolithic re-renders.

Details

Key	Value
Target Audience	Power users of programmatic CAD (OpenSCAD, CadQuery) who need to debug complex, nested geometric operations involving many booleans or CSG trees.
Core Feature	A live-reloading environment where editing the code updates the AST view immediately. Users can select a specific node (e.g., `difference(A, B)`) and instantly render only that resultant mesh or bounding box, bypassing the full scene re-render.
Tech Stack	Monorepo structure: Language Parser (e.g., using ANTLR or similar tool for target language), Editor (Monaco Editor), 3D Viewer (Three.js/Babylon.js), Backend: WASM compilation or fast local invocation of rendering engines (like OpenCSG).
Difficulty	Medium
Monetization	Hobby

Notes

This directly solves the critical workflow element users praised: "The immediacy is mostly thanks to OpenCSG which is essentially a magic trick to quickly fake 3d rendering of booleans... Being able to interact like this makes it much quicker and easier to iterate on a design." (aclindsa).
By targeting the AST, it accelerates debugging when "panning around with ortho view, it didn't need to re-render" (beeflet implies the engine is fast at primitives, but complex booleans are slow).

"LLM-to-CAD Kernel Intermediate Representation" Generator

Summary

A lightweight, strongly-typed, and highly structured Intermediate Representation (IR) language designed to be the target for LLM code generation efforts, overcoming the common failure mode where LLMs produce syntactically correct but geometrically invalid code in languages like OpenSCAD.
The IR is simple, focused only on core geometric primitives and boolean operations, ensuring LLMs remain constrained to producing reliable output, which is then translated to OpenSCAD, CadQuery, or other backends.

Details

Key	Value
Target Audience	Developers building AI-assisted CAD tools, or end-users who heavily rely on LLMs for initial drafts and want guaranteed structural validity.
Core Feature	A Domain Specific Language (DSL) with strict schema validation enforced at compile time. If an LLM generates an operation that creates mathematically impossible geometry (e.g., intersecting solids without an expected union/difference), the IR compiler flags it immediately, unlike less strictly typed languages.
Tech Stack	Language implementation via Rust or Haskell (for strong type guarantees and ease of parsing). Compiler frontend emitting validation reports, backed by backends that translate the validated IR into targets like OpenSCAD scripts or Python (CadQuery).
Difficulty	Medium
Monetization	Hobby

Notes

This addresses the core LLM interaction issue: "I then tried to get it [an LLM] to write a module to extrude a 2d shape into a 3d shape and it failed spectacularly several times before I gave up" (aclindsa).
Providing an IR that LLMs can easily learn to target (since it's simpler/more structured than general-purpose CAD languages) makes programmatic CAD more accessible via AI assistance, fulfilling the vision mentioned by lovemenot.