https://acornprover.org
Also doing some software work on the DSA-2000, a next-generation radio telescope going up in the Nevada desert:
https://www.deepsynoptic.org/overview
Previously, looking for aliens:
https://lacker.io/physics/2022/01/21/looking-for-aliens.html
Before that, I was the founder of Parse (YC S2011), the simplest way to build a mobile app. We were acquired by Facebook in 2013 and had a few exciting years there.
Unfortunately, we shut down the hosted Parse service in January 2017. Fortunately, a lot of the Parse magic lives on as open source:
https://github.com/ParsePlatform/parse-server
Before Parse, I founded Gamador (YC W2010). Millions of people have played Gamador's casual games.
Before that, I was a software engineer at Google working on search algorithms.
Before that, I was in grad school at Berkeley bouncing around between computational biology and AI.
You can follow me on Twitter: http://twitter.com/lacker
My email is just my hn username at gmail.
[ my public key: https://keybase.io/lacker; my proof: https://keybase.io/lacker/sigs/Jhx53TkSPU1FfKRiXpL5WXxSlr9XMDZgSlaIcEOpU_c ]
- lackerI'm not sure if I have the right mental model for a "skill". It's basically a context-management tool? Like a skill is a brief description of something, and if the model decides it wants the skill based on that description, then it pulls in the rest of whatever amorphous stuff the skill has, scripts, documents, what have you. Is this the right way to think about it?
- At first this sounds cool but I feel like it falls apart with a basic example.
Let's say you're running a simple e-commerce site. You have some microservices, like, a payments microservice, a push notifications microservice, and a logging microservice.
So what are the dependencies. You might want to send a push notification to a seller when they get a new payment, or if there's a dispute or something. You might want to log that too. And you might want to log whenever any chargeback occurs.
Okay, but now it is no longer a "polytree". You have a "triangle" of dependencies. Payment -> Push, Push -> Logs, Payment -> Logs.
These all just seem really basic, natural examples though. I don't even like microservices, but they make sense when you're essentially just wrapping an external API like push notifications or payments, or a single-purpose datastore like you often have for logging. Is it really a problem if a whole bunch of things depend on your logging microservice? That seems fine to me.
- I feel like Zig is closer to "better C" and Rust is closer to "better C++". So I'd pick based on whether you are more in a C mood or a C++ mood.
- The real risk is not that Anthropic will run out of money, but that they will change their strategy to something that isn't Bun-based, and supporting Bun won't make sense for them any more.
- A similar problem that I like.
A "lattice point" on the plane is a point where both coordinates are integers, like (3, 4) or (-2, -1). Prove that for any five lattice points, there will be two of them that if you connect them with a line segment, there's another lattice point between them on that line.
- I think Ruby has declined because Rails was its selling point, but Rails was optimized for the world of HTML templates. Once you're writing JavaScript-heavy frontends and mobile apps, Rails isn't giving you much that you can't get from Python or server-side JS.
- Something people want, apparently!
- I was riding in a Waymo recently and it suddenly braked for no reason at an intersection where it didn't have a stop sign. I was like, what the heck, this Waymo is broken, it didn't see that the stop sign is only two way. Then a little kid on a bike riding along the sidewalk at an angle where I hadn't seen them just barely braked to a halt before riding into the street in front of the Waymo.
These things must be saving lives, it's obvious. When my kids are riding their bikes around I want the other cars to be Waymos, not human drivers.
- Obviously it's property damage. How would you like it if someone covered the windshield of your car with glue?
- It makes sense to me that criminals, like this guy you met in a bar, are opposed to Flock cameras.
- There are a lot of Flock supporters out there. In my neighborhood, homeowners can volunteer to put Flock cameras on their property, and a number of people are doing this.
It's like having a Ring doorbell and sharing the feed with the police, which is also pretty popular in some areas. If you trust your local police to ethically fight crime, why not help them out?
- Oh... that explains what's happening here.
It's frustrating for the participants, but typically for these "internship programs for disadvantaged students", future employers will not treat it as equivalent to a regular internship.
That includes the company that runs the internship. In my large tech company experience, usually the entire "internship for disadvantaged students" program led to zero job offers.
Honestly, it might be a good idea to avoid those programs entirely. You often don't get to work on "real problems" while you're there. The program exists for PR much more than to give you useful experience.
That said, I don't have experience with this specific program, so this might not fit the archetype.
- I don't intend to say the author is "bad", I'm just trying to follow up on this reasoning:
I learned the tools I was told to learn. I watched the right talks. I followed the right people. I can point at a neat little row of experiences and say: I played by the rules you told me about.
The rules are, do well at your internship, and you'll probably get a job offer.
The author also seems to be saying that they are getting interviews, but no job offers. ("The interview loops still exist, recruiters still send polite rejections.") Another rule is, if you do well at interviews, you will get a job offer.
So, without putting any value judgment on anyone, this is what's happening. The author isn't doing well enough on internships and interviews.
So my advice is not "just apply to more places", but to do that and also practice programming in order to interview better.
- What jumped out at me is that the author had three internships. Those are essentially "entry-level positions". If you do well at an internship, you typically get a job offer. If you don't do well, usually you can at least get some useful feedback.
I'm not saying that everything is perfectly fine in the job market right now, it's just a lot more productive to focus on "what skill do I need to work on, that would have let me convert those internships into full time jobs", rather than "man the job market is bad".
- I personally like AI but it has definitely shifted my job. There is less "writing code", more "reviewing code", and more "writing sentences in English". I can understand people being frustrated.
To me it's like a halfway step toward management. When you start being a manager, you also start writing less code and having a lot more conversations.
- The point I found most interesting is what the author calls "robustness".
Another advantage of AlphaEvolve was robustness: it was relatively easy to set up AlphaEvolve to work on a broad array of problems, without extensive need to call on domain knowledge of the specific task in order to tune hyperparameters.
In software world "robustness" usually implies "resistance to failures", so I would call this something different, more like "ease of integration". There are many problems where in theory a pre-LLM AI could do it, but you would have to implement all this explicit modeling, and that's too much work.
Like to pick a random problem, why does no superhuman AI exist for most video games? I think most of the difficulty is not necessarily in the AI algorithm, it's that the traditional method of game playing involves programming a model of the game, and for most video games that's an incredible amount of work, too much for someone to do in their spare time.
LLMs, on the other hand, are decent at integrating with many different sorts of systems, because they can just interoperate with text. Not quite good enough at video yet for "any video game" to fall. But a lot of these problems where the difficulty is not "algorithmic" but "integration", the LLM strategy seems promising for cracking.
- Batteries are also a pretty good solution. It's possible that eventually there is enough battery storage on the grid that we can shut down the highest-risk transmission lines for longer periods of time without having power outages.
Casey Handmer has some interesting writing for people who are curious about this direction: https://caseyhandmer.wordpress.com/2023/07/12/grid-storage-b...
The nice thing about batteries is that they get cheaper and cheaper over time, as opposed to generic construction in California, which seems to get more and more expensive over time.
- In my Mazda the wired CarPlay also seems to fail a lot. But whenever I rent a car with wireless CarPlay it's been fine. Take this one anecdote for what it's worth.
- CarPlay has its pros and cons. I drive a Mazda and have rented enough GM and Ford vehicles to say that all of their software is consistently terrible. It's like every rectangle on the screen is built by a different team, all of whom hate each other. Different fonts, different modes of interaction, buttons that do nothing, error messages that complain about other parts of the software. So CarPlay is much better than any of those.
But at the same time I don't really use CarPlay for all that much. Music, maps, that's about it. And I also want to use the screen for some features that CarPlay doesn't handle, like checking backup or side cameras. In theory you could do even more, like if I have some engine problem why does it alert me with a few words in a tiny amount of UI in some random spot? It could give me a full explanation of what's going wrong, tell me whether it's in warranty, and offer me to schedule an appointment, right there from the screen in my car.
I haven't driven a Tesla or a Rivian so I don't know how good their software is. But it does seem like there's an opportunity to build some actually-good software here that a generic platform like CarPlay can't really do.
- Yeah, I just meant proposition-as-types. Sloppy terminology by me. I meant to complain about the general conflation of the "proving system" and the "typechecking system".
Generally in dependent type systems you are limited in some way in what sort of values a type can refer to. The fancy type checking happens at compile time, and then at run time some or most of the type information is erased. The implementation is tricky but the more difficult problem IMO is the developer experience; it involves a lot of extra work to express dependent types and help the compiler verify them.