I won't stand for Carter slander: he was a darn good president too. What he wasn't good at, was politicking, and that was because he also was a good man, to a fault. He gave an honest answer to a question on if he had ever lusted after a woman who was not his wife, and reaped a scandal.
No way that created the modern Islamic Iran. Carter supporter the shah. To the extend USA decided the outcome, it was by supporting the shah for too long, and for the US role in the 1953 coup.
But IMO the USa played third fiddle in that story, this was between Ruholla and the shah
I just listened to a the rest is history podcast and he had a few things he was lacking and wasn’t particularly flattering but he was an upstanding citizen at the very least.
So if you are using multiple languages to have scripts that run off your pre-commit hook, this is like a package and language runtime management system for your pre-commit hook build system? Rather, I think this is a reimplementation of such a system in rust so it can be self contained and fast.
This is the kind of thing I see and I think to myself: is this solving a problem or is this solving a problem that the real problem created?
Why is your pre-commit so complicated that it needs all this? I wish I could say it could all be much simpler, but I’ve worked in big tech and the dynamics of large engineering workforces over time can make this sort of thing do more good than harm, but again I wonder if the real problem is very large engineering teams…
>I still feel like there's an unexplored space where you combine the benefits of both somehow though. Like a code-based CAD but it also has a GUI editor that stays in sync and avoids the need to type in coordinates by hand. That would be extremely difficult though.
I think you can do this if the data representation of operations and values is human readable. The simplest implementation would restrict the language/data format to operations representable in the gui.
Unlike trying to solve the "visual programming" problems, we don't need or desire Turing completeness.
>Compare that to someone writing embedded firmware for device microcontrollers, who would understandably be underwhelmed by the same.
One datum for you: I recently asked Claude to make a jerk-limited and jerk-derivative-limited motion planner and to use the existing trapezoidal planner as reference for fuzzy-testing various moves (to ensure total pulses sent was correct) and it totally worked. Only a few rounds of guidance to get it to where I wanted to commit it.
My comment above I hope wasn't read to mean "LLMs are only good at web dev." Only that there are different capability magnitudes.
I often do experiments where I will clone one of our private repos, revert a commit, trash the .git path, and then see if any of the models/agents can re-apply the commit after N iterations. I record the pass@k score and compare between model generations over time.
In one of those recent experiments, I saw gpt-oss-120b add API support to swap tx and rx IQ for digital spectral inversion at higher frequencies on our wireless devices. This is for a proprietary IC running a quantenna radio, the SDK of which is very likely not in-distribution. It was moderately impressive to me in part because just writing the IQ swap registers had a negative effect on performance, but the model found that swapping the order of the IQ imbalance coefficients fixed the performance degradation.
I wouldn't say this was the same level of "impressive" as what the hype demands, but I remain an enthusiastic user of AI tooling due to somewhat regular moments like that. Especially when it involves open weight models of a low-to-moderate param count. My original point though is that those moments are far more common in web dev than they are elsewhere currently.
EDIT: Forgot to add that the model also did some work that the original commit did not. It removed code paths that were clobbering the rx IQ swap register and instead changed it to explicitly initialize during baseband init so it would come up correct on boot.
Ah yes the magic is more developed for commonly documented cases than niche stuff, 100% sorry I misinterpreted your post to mean that they are not useful for embedded rather than less capable for embedded. Also, your stuff is way more deep than anything I am doing (motion planning stuff is pretty well discussed online literature).
It's remarkable how these papers show a deep understanding of programming 50 years ago. Even with anemic hardware, the limit is always in the programmers brain - as uncomfortable as that is to admit. Half a century of new tech and AI and the cloud etc, we still hit "terminal trauma" fairly quickly in the development cycle, almost like clockwork. All the tools and technical tricks don't seem to matter vs. our ability to hold the application in our heads.
Trying to get my Klipper-like thing for ClearCore up and running (currently called Cutter) so I can have a smaller mostly unchanging c++ codebase on the mcu and do higher-level application control of motors, outputs and sensors on linux in rust.
reply