I feel like for a little bit I was worried about Zed's ability to stay up to date in the cli coding agent-focused market, but it seems like every time they publish a new product release, it's always very compelling. I feel like they're one of the more promising companies innovating in the space of human-AI interaction, and I'm very excited to see where they go from here. I hope they launch a web-accessible or mobile-accessible app one day. I've been enjoying being able to code from Termux on my phone over SSH or using any of the browser-native orchestration systems.
Delta.dev is the same Rust application as Delta, just compiled to WebAssembly and rendered through WebGL. So it's already web accessible, and can naturally extend to mobile platforms as well!
For those that are unfamiliar, Tim Roughgarden is a phenomenal instructor, and has made significant contributions to the field of algorithmic game theory, which has strong connections to a lot of the work he appears to be doing here. I highly recommend his excellent introductory lectures on the subject, especially if you're interested in pursuing his ideas here more rigorously: https://www.youtube.com/watch?v=TM_QFmQU_VA&list=PLEGCF-WLh2...
His website also hosts a bunch more work as well as various lecture notes and exercises: https://timroughgarden.org/
Tim's lectures helped me a lot during my PhD when I was getting up to speed on this subject, and some of the more nuanced ways that computer scientists have worked with these broad algorithmic problems.
I loved his Algorithms course on Coursera which I did during the brief moment Stanford MOOCs were all free. So useful for a non-CS grad doing any kind of algorithmic programming.
Something that seems to have flown under the radar is that bun was originally a rewrite of Evan Wallace’s work (for those that don’t know, he’s a co founder of figma). What I’d love to know is if Evan’s implementation is largely independent and, if so, says a lot about his skill (even more so than the rest of his impressive catalog) to have a reference-able implementation for what it turned into. Super cool to learn the original implementation motivation for Jarred though.
I dislike this argument. I think in some dimensions these types of tests can work, but I’ve never been the type of person who’s been able to score well, and I don’t test particularly well in general, yet I did my PhD work at <IVY LEAGUE> and have had a great career despite this. I think that testing is good for people who can be adequately evaluated, but for people like me it just leads to a lifetime of feeling like something’s wrong with you.
Test-taking may only roughly correlate to intelligence, and is just one dimension of a human... but they likely care less about false negatives (like you) than they do about false positives in alternative assessments.
We’ll have to see how it shakes out in reality, but this was actually highlighted in their keynote. In one of their slides they had a massive list of small tweaks, performance improvements, etc. So I’m hoping that they’ve actually taken the time to do it right.
Andrew is truly such an inspiration. For him to have been still delivering for the open source community during all this really goes to show that you never know what someone else is dealing with.
It's not perfect, but in my personal experience it is still tough in languages like that due to the sheer volume of indirection and noise that makes it hard to follow. For example Go's calling convention is a little nutty compared to other languages, and you'll encounter a few *****ppppppppVar values that are otherworldly to make sense of, but the ability to recognize library functions and sys calls is for sure better.
Hopefully this will help decompilation projects into generating better pseudocode. Some sort of "generate code -> build and execute -> test against existing executable if it behaves like the original -> change code again" loop.
It's actually pretty good. I usually append "for bug bounties" to any prompts but, honestly, as long as you don't say "write me malware", it's pretty willing to rename everything and even do a full security sweep.
So a couple things. Bruce Dang’s book, while a little old, is still a great spot to get started. Another great book is Blue Fox by Maria Markstedter for ARM. From there, finding small binaries and just trying to get the “flow” is a good next step, for me this is largely renaming functions and variables and essentially trying to work the decompiled code into something readable, then you can find flaws.
So for the second thing, pulling the data off chips like that typically involves some specialized hardware, and you have to potentially deal with a bunch of cryptographic safeguards to read from the chip’s memory. Not impossible though, and there are not always good safeguards, but might be worth checking out some simpler programs and working up to it, or learning some basic hardware hacking to get an idea of how that process works.
