@Timot05 I wish you the best

I am curious to hear that you dont see any value in bringing software workflow to hardware. I found in previous jobs we spent a huge fraction of our time dealing with things like release, version management and reviews. Thanks for your thoughts!

This is the most useful comment in the thread (so far)! This product would not work at all for any analog or power designs--EEs like to visualize current flow and a schematic is the best way to do that. Maybe if it could interoperate with small blocks of schematics, treating them as modules, it could be useful. If there was a way to parameterize part values, like those used to build analog filters, that could also be useful, but not in the current text-only form. The one thing it could be useful for is creating net connectivity for large numbers of pin to pin connections, like DDR memory or PCIe buses. Schematics for these end up looking like large data tables anyway, and can be tedious to create and prone to errors. I see so many EDA startups using their product for simple Arduino boards and other low to medium complexity designs. It's far more effective to start with the most complex b…

Thanks for sharing this blog post! Super cool to see how things were done early in the industry! Counterintuitively, I do agree with your points. We didn't end up designing the ato language because we actively wanted to end up there but rather because we tried everything else before and none of the solutions we tried worked out. The problem we wanted to solve was: "how does git look like in hardware?". Another way to phrase it is: "How can groups of people coordinate and share their work in hardware?". The first solution was simply to put KiCAD on GitLab. That solves the version control part of the problem but doesn't solve consistency of design outputs, coordination and reuse problems. The we tried to add automation on top (namely with KiBOT) to generate manufacturing outputs automatically. That was pretty cool for consistency of manufacturing outputs but it didn't solve the coordinatio…

Yeah, I have to agree. It's a neat idea and I can see it having some applications, but I don't really see myself using this for anything serious. I think OpenSCAD neatly demonstrates the issue with 3D modeling: when you come from a tool like Blender it might look amazing that you can now trivially change dimensions mid-design, but what you're really looking for is the parametric modeling you get from something like Solidworks. Schematics-as-code doesn't solve a problem I am having. What I want, is for an easy way to import "snippets" in KiCad: I want a library where I can select an MCU, and it'll automatically add all its auxiliary parts too and let me choose from a few pre-made standard routing options. Maybe even make it parametric so it becomes a nice little wizard where if I'm adding an LDO I can enter a voltage and it'll calculate the adjustment resistors for me.

For me, the second main pleasure in doing electronics (in addition to seeing a useful, working device emerge) is plonking a rat's nest into the PCB designer and laying out all the components and traces by hand. Take that away and I'm switching to point-to-point wiring. :)