[polalavik]

I was thinking the same thing (I'm an EE by day). I think this idea is very cool, but since the dawn of time schematics and PCB layout have always been visual because you are actually building a physical thing. Its easy to see hardware bugs in schematics visually. However, it might be very hard to track it in code, unless the code is one day smart enough to find the bugs for you. You have to hold more context in your head that you cant export to your visual senses when its written as code. You cant see the actual circuit flow.

edit: just wanted to double down on this being very cool though. i dont mean to deflate this project and I'm about to design a pcb for a personal project - I might give this a go for fun. the promise is there and asthe project and feature set grows i can see it being the way forward.

[napowderly]

I have found taking a 'functional programming' like approach, where you build up your circuit from small blocks with specific functions that are easy to hold in your mind and then building up by combining those. For example instead of sticking a bunch of resistors and caps in your top level file, you can abstract them into their functions like a filter, resistor divider etc. Very curious to get your thoughts on using the tool!

[cmos]

I agree - also an EE - and I think it is similar to 'programming music' packages like Sonic Pi. If you are used to reading and writing standard music coding will be an odd and difficult change. Right now we have a comfort for seeing the layout and such physically, and since that is how we manufacture it this is going to be an output anyway, but there is some future world where it is all put together automatically within the requirements we specify and we have an entirely new way of designing circuit boards. Each component would come with not only a footprint but an array of basic design implementations that would mix and match with others.. autorouting on steroids of sorts.

[Timot05]

We do agree. We built an early version of a viewer in the project but later moved away from it because it wasn't good enough to interact with. We might come back to it with something that is more targeted at inspecting only sections of the circuit or provide a block diagram level representation. But we don't think that just outputting a schematic the way they look today is the right solution.

[whartung]

I worked on this for a little while myself.

It wasn't so much "pc board by code" so much, but it was more a "pc board by CLI" approach.

And by that what my goal was, was to offer primitives and utility functions that would build the board up over time, but it was to be done incrementally in a Lisp REPL.

My use case scenario, was ancient AutoCAD.

Back in the day, while you could hook up a tablet or other pointing device (I'm talking pre-mouse here) to make AutoCAD drawings, a lot of it was done simply through typing in commands, in AutoLISP.

(lineto 100 100) kind of thing. And the drawing would appear on the screen over time, you'd save the data model, and manipulated with the REPL. If you wanted 10 lines:

    (dotimes (i 10) (let ((x (* i 10)) (y 100)) (line x y x (+ y 100)))

(HN does not have a paren matching editor, apologies...)

Where it broke down for me was coming up with a graphic rendition using CL.

If emacs had anything reasonable regarding graphic support (its SVG support is Not Good), I'd have done it there.

Rethinking it, it just occurred to me I could have probably gone a good way using ABCL in a Java GUI shell.

But the key point is that I think using a REPL for building up something like a circuit can actually work, actually be efficient for users, especially if it's extensible (i.e. (defun grid ...) ). Especially a hybrid (like clicking on a line pastes an identifier into the REPL).

My experiences with KiCAD drove me down that mad hole.

[techdragon]

You might find this a stumbling point for adoption. My first thought is this could be a good tool for me to use, but how can I send a design to someone else to get feedback on if I’m not going to expect them to also also learn how to use this or how can I get my design manufactured if the tools can’t export out the, normally very visual, layout files.

[Timot05]

I do think that is fair. The reason that we don't have a visualizer is not that we don't want one, but rather that the value to effort ratio is quite low (and really because the effort is high, not because of low value). I'm sure we'll get there at some point. But at the moment there are more pressing issues for the people who are ok dealing with no visualization (like typing, language server, equations etc...).

[techdragon]

I’d definitely consider not letting some basic visual schematic outputs fall too far down the priority list.

A lot of existing EE is basically just the visual diagrams and a lot of existing EE people will expect the tools to give them the visual diagrams they work with somehow… like even just including the compiled schematic as an SVG in with the compiled outputs of netlist, gerber, etc… something that other software can be used to convert to PDF without extra complexity in your tool and can be used to interoperable with the existing talent pool of EE people who have not just no idea how to use your tool… but know how to read typical style circuit diagrams.