Timot05

agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax. LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.

I’m relatively new to programming but I wish they had used a functional language syntax rather than an object oriented one as the basis for mojo.

From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe.

I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.

Nice kickstand!

Skip to 6:22 for the action. Feedback is welcome. Thanks!

Honored to be there!

Thanks! And glad you are making your way towards electronics.

Yes, we hope for the packages.atopile.io to become a place where you can share your designs and explore what other people have built.

Pain might not have been the right word indeed. The aspect we wanted to point to was rather the fact that we had to do it over and over again. And so from that perspective it became a “pain”.

Ultimately we do love electronics. This is one of our attempts to contribute back to the field.

Thanks for sharing! We will have a look

Thanks for your detailed answer! Tons of information in there.

To your point about how the work gets divided, I don't think that work will necessarily be distributed amongst many people for a given design but code gives you a couple of benefits:

- you can branch and merge the changes you make, which means that you can design a given feature and have your team review only this change instead of reviewing a batch of changes.

- If someone actually does want to pickup your design and wants to contribute to it, code makes it easier for them because more information is captured in the code, so they get a better sense of what the design requirements are.

To your last point, we don't really see the code becoming the documentation of the implementation of the module. Actually the goal is to do something similar to the IC space or the software space, where the code becomes the implementation of something but the documentation lives somewhere else, perhaps in a datasheet-like document. Currently the schematic forces you to have both the documentation and the implementation baked into the same document, which forces you to find a middle ground between adding information relevant to those two objectives.

Fully agree! We'd much rather be in a situation where criticism is consistently thrown at the project so we can further improve it rather than having positive feedback and the discussion just stopping there.

Thanks for sharing the docs! Our language is mostly declarative at the moment. There are some features we discussed that would be imperative and we might introduce them in future versions of the compiler.

Well designed schematics are great. Especially if you are sharing them with your team as documentation.

The point we would like to move towards is one where atopile enables you to generate high quality documentation about your design in a similar fashion to a datasheet but not entangling the documentation with the source design, which is what a schematic forces you to do. There are some features we'd want to build that could enable that like a visualizer for important parts of a schematic, a fan out view of the consumed interfaces around a chip, the results of a spice simulation...

Autorouting would for sure be a valuable tool to add to EEs toolchains. The reason we focused on the language first is because it is critical to provide high quality information to autorouter for them to do a good job. And achieving that with a schematic is tough, as it only captures part of the information required to doing a good job laying out the circuit. A bunch of information is currently implicit.