sroerick

My Google account was not compromised. I wouldn't touch Polymarket ever again. There is some kind of massive scam happening here.

I feel like this is the new "test driven development", which is totally a good idea, but also not totally useful for the actual process of building web apps, where most of your failure modes are weird CSS, JS, or server issues.

I would be happy to be proven wrong though

As I see it - you need to track spec (a declarative process) and also tasks/progress (an imperative process). You do need to manage blockers so tasks should largely be a dependent graph.

There's also a third thing which emerges - which is "design decisions along the way". I do actually keep this in the repo as well, but I'm not sure this is correct.

Beads combines all three, which I'm not sure is correct, but seems quite brilliant.

But you know what I mean, right? What would be a better way to describe it?

I think the Lisps kind of have up on being an interpreter and I feel they lost some of their power because of it.

I kind of see Ruby waning right now, I don't think it offers much with the development of LLMs. I don't think adding typing is the key - but I anticipate there will be a kind of LLM-powered Smalltalk resurgence

Performance is a consistent issue. Ive had to build a lot of optimization and benchmarking tools in order to keep things functional. Every couple of weeks I have to refactor everything to keep load times good. Both on the database side and on the lisp side. The models, by default, will happily build functions with 26 database calls or millions of recursive steps.

More frustrating, though, was probably the 3-4 weeks when i migrated the storage concept to "one big tree". This was an aesthetic thing that I later found out some of the old lisp machines also did. But - I didn't think about it initially when I built it. And switching things at that low level was difficult. There was a lot of legacy data stores along the way and programs were using the old store constantly. Very irritating. I still wonder if it would have been faster to just completely rebuild at that point.

An ambitious user could probably run it themselves and have it function, or I think I could run it as a managed service for somebody and have it be good, but the UX is still not really ready for primetime

It still needs a lot of back and forth before I'm comfortable it's not doing slop architecture, but once it's on thesame page as me it genuinely is better at it than me.

I'm not sure that there is a "One Size Fits All" software factory out there. I think that they kind of have to grow with your organization.

However, I think being able to build a software factory is probably a very useful skill. And it feels pretty great to just send a list of bullet points over XMPP and know they'll get integrated overnight.

I just don't do this at commit time. I might make 100 commits and then dig through code and find some bad architecture stuff.