> It's very cool you managed to make a mini Pathom - esp in so few lines of code :))
Thanks! The possibility of doing this had been on my mind for a while... and then I finally got around to trying it since all I had to do to get started was say "try making something like pathom but without [...]". I actually have all the prompts and feedback for the initial POC over here[1] since at the time I was using github issues/comments for my LLM-driven-development workflow.
Over the past few weeks as prep for release I went over all the code manually (especially since the whole point of this thing is for the implementation to be easy to understand) and basically rewrote the whole thing, or at least that's what it felt like.
> But the end result looks almost identical? Resolver declarations are a bit reorganized and look a bit cleaner - though you could do that with a wrapper around Pathom. Why not fork Pathom and just make some QOL adjustments?
The main thing I was going for was just to reduce the implementation size; the tweaks I made to e.g. `defresolver` were really just a side thing. To give some more background on the motivations, an issue I've had sometimes with Pathom is figuring out what's going wrong when my queries don't give me the results I'd expect. A few times as part of that I've gone spelunking through the Pathom codebase but still had never built up a complete understanding of how the query planning and execution works, which has meant that my debugging has always been more trial-and-error / black-box than I'd prefer. So I wanted to see "what is the least complex way that I could take an EQL query and figure out the results, even if the way I do it is dumber than the way Pathom does it?"
i.e. I'm trying to minimize the amount of time it takes for someone to read the code and understand exactly what's going on under the hood. Hence layering more code on top of Pathom would only hinder that goal.
Yeah, it's a big eye-opener. I'd like to see if I can figure out an ergonomic way to do it in Python since I do a fair amount of work in that, and passing ORM objects around isn't great.
AI has been working out well for me writing Clojure, both in personal projects and at work. Documentation, not so much... I write all that by hand.
For Biff I've been using AI to generate a rough draft of all the code and then I take a manual pass over things before releasing. Seems to be a good middle ground.
As the author of a different project also named Biff, I do have to warn you that half the comments on your HN posts will be people quoting back to the future--though I haven't decided yet if that's annoying or an engagement hack!
I applied 9 times and never got an interview. I've moved on from entrepreneurship (for now?), but would love to know what percentile I'm in for consecutive rejections as a consolation prize ;)
True, but in many cases you can still offer a service for free without ads. E.g. offer a free version with limited functionality, and then offer a paid version with features that are needed mainly by people who use your product for work. Even if ads weren't an option, it's still advantageous to get lots of people using your product, and I think companies will continue to find ways to do so.
I don't really care if ads stop being profitable. If ads stopped being a good source of revenue, the tech industry would adapt, and my guess is that the end result would be much more favorable to society. I'm working on an early-stage startup right now, and I'm certainly not going to use ads as part of my revenue model.
Google might not be too happy about an outcome like that, but I'm not overly concerned about Google's wellbeing. :)
I'd be interested to hear your thoughts on this since you work on ads: are ads actually essential in the software industry, or could we do just fine without them?
Working at https://tyba.ai
Building https://yakread.com and https://biffweb.com
email: [email protected]