Watch his lecture series on YouTube. We you started programming, you had to adapt your brain to the way of thinking of computer programs. Think of this as an continuation of that evolution, were you acquire new methods of reasoning that can abstract many apparently different problems into the same concept.
In a different comment thread, someone mentioned the book, Category Theory for Programmers. Here's the Releases page with PDF files (click to open the Assets section). https://github.com/hmemcpy/milewski-ctfp-pdf/releases
There are several versions with code examples in Haskell, OCaml, ReasonML, and Scala. These are all typically associated with functional programming and category theory. However, category theory is a much wider and deeper subject than any specific language, and deals with mathematical objects and concepts relevant to (more or less) all of programming.
Please check these SDR based wireless communication book and course by Qasim Chaudhari namely Wireless Communications From the Ground Up: An SDR Perspective as per my other comments.
No, it's exactly the sort of projects slop is not appropriate. If you're going to use this in production, at least using LLMs (maybe) allows you to deliver faster.
Just had a quick scan through it. ToC is a bit rambling. Content sample isn't enough to judge the whole book. I'll reserve judgement. It looks considerably better than Practical Electronics for Inventors and several orders of magnitude better than Mimms' and Make garbage.
Probably a good start. We shall see.
I was going to write my own book on the matter but quite frankly I don't have the time or energy for it.
An LLM-only oriented language doesn't make sense, because without human generated training data there is nothing for the model to learn from.
But if a human-oriented language were to be designed to also be better for LLMs, I think it would involve deeply expressive syntax that can succinctly but distinctly represent a very broad set of common operations. Succinct so context can be managed well, distinct so completions don't confuse one thing for another, broad so as much "reasoning" can be taken away from the LLM as possible. An anti-C. A new take on the goals of Java and Go to be languages that protect the application from the Junior Developers You're Likely To Hire.
I somewhat think it would also involve application state images ala Smalltalk. LLMs seem okay at generating small deltas. Many deltas sequenced together invites compounding error. LLM generated apps are unlikely to lead to common libraries being compentized and extracted out of the application to share with other applications; it seems like LLM code generation is already a "married to a specific project" act already. So, having a living state image might reveal some benefits by leaning into incrementally developing the application in situ, as a whole.
I would guess a good way to implement a language meant for LLMs would be to strip out as many features as possible, so that all programs needed to be composed of just a handful of common structures written in shorthand. As much compiletime enforcement as possible. Maybe human-crafted abstractions for more error-prone concepts like multithreading that limit how they can be used in the language but provide ample, testable bumpers.
It would be interesting to design some mechanism where an external actor could program extensions into the language easily, which then would become a new black-box tool that an LLM could program with. Ideally though, I think you want to remove as much agency in reimplementation and re-abstraction as possible from the LLM. This is really just some tier above current high level languages, with as much dumbing down as possible.
I'm not sure this is really necessary or would even be effective because there wouldn't be a million examples for the training data of an LLM. But I imagine something along these lines could make an LLM more productive and token efficient.
I don't know but I would imagine there are a lot of inefficiencies in modern languages from an LLM perspective that it could strip out, reduce token costs, improve speed etc.
There are already plenty of PLDI and SIGPLAN talks on LLM => Assembly, with some guardrails for determinism, instead of having a "classical" language as translation layer.
Sorry are we referring to the efficiency of generating programs (i.e. optimizing LLM software development) or the efficiency of the output (i.e. optimizing software through the generation of assembly)?
I've been watching this space closely and have been on the lookout for new releases. Besides "Building Git", there is also "Building a Debugger"[0], "Writing a C compiler"[1], "Crafting Interpreters"[2], "The Raytracer Challenge"[3], and a few others that I can't vouch for as they appear to be low-quality compared to the ones I listed out.
The potential for technical authors in this space is enormous.
Yeah. I did it in Rust only, but went a bit farther than the book and implemented some constructs that were not found in the book. I was able to compile my other compiler written in C with the C compiler I had written in Rust.
But can you run it on their platform? NO, you need to run it on your own machine which takes a bit of work. And we have over 80 courses waaay over whatever codecrafters has
Isn't that the best part of codecrafters? Being able to just use your own text editor instead of a janky web based one which loses everything you typed on page refresh?
You were right, and this comment stuck with me so I have decided to go ahead and implement it.
Every course now has a "work in your own editor" mode: you can download a zip with the starter code for every lesson plus a run_tests.sh that runs the full test suite locally. After that, you can push it to a public GitHub repo, we will judge it based on our grading system and internal tests
