esmevane.com
Insipid but well-meaning software developing art gremlin.
"Incoherent; mayhem." - 4/5 stars.
"Couldn't make any sense of any of it, it's like he's talking to himself." - 2/5 stars.
https://mastodon.esmevane.com/ironchamber
https://esmevane.com
1,608 posts
147 followers
251 following
Regular Contributor
Active Commenter
comment in response to
post
Well that’s actually kind of a relief. Does it have a lot of new view code? I mean lots of the time a few new pages swell up a PR a lot
comment in response to
post
Right. At first I thought she was talking about transpiling or doing multiple langs on top of a vm style setup, but no
comment in response to
post
I haven’t been able to find it but I swear I’ve been looking! It was on my hosted Mastodon instance, which doesn’t have search, so who knows how to turn it up.
I will say that it didn’t seem like she had prior art. But still, she knew her stuff so I’d at least like to point you her way if I can
comment in response to
post
I mean you never know. Some people can drop those huge 80% test + 20% pinpoint precision change PRs. It happens, and I love reading those
comment in response to
post
If it’s not 1200 lines of tests, and some new config / artifacts checked in, then I’d probably ask to pair with them and have them walk me through the big parts. Otherwise it’s gonna be hard to find the focus to do meaningful reads on it.
comment in response to
post
You know what, that isn't what I was thinking of but you're making an excellent point w/ this. I should dig deeper into tree sitter!
I can't recall who talked about the AST lang, but she was basically describing a lang meant to go under other langs, so everyone could just pick their fave to work in
comment in response to
post
same - that's where I'm getting the "write only" comments from. It seems like, given a world where generating can work and maintaining is a huge hurdle, regenerating a lot of throwaway things is what people might trend towards. So uh, making programs in a way similar to db migrations, maybe?
comment in response to
post
Ohhh - so, not exclusive to models but just a general OS w/ its parts reconsidered for an unknown amount of arbitrary collaborating actors? That's a really cool thought, if so. Thanks for expanding
comment in response to
post
I think that's right. It's all changing so fast, and like you say the first problems we puzzle out are the obvious ones. I'm guessing there's gonna be a lot of focus on generating vs. maintaining, so maybe something good for maintenance will emerge (even if it turns out to be part of a new approach)
comment in response to
post
fwiw I think the core issue here isn't "it's too hard" but the overall model architecture and the feedback systems it couples us to
we're talking about a part of the process which is laborious to delve into if you can't get constant, fast feedback, so something tiny/custom fit seems necessary to me
comment in response to
post
I think I wondered about this a few months ago in a PL thread!
I heard someone talk about an AST substrate for multiple languages to map to. If we treat models as an interface w/ new instruction paradigms, it might be an ideal generation target.
Is that kind of what you're saying?
comment in response to
post
Like if we were to project the "viability score" of generating vs. maintaining, an expert would be someone with a high viability in both but most other folks would be able to start out high in generating, there's a big gap for them to cross before they get a high viability in maintaining.
comment in response to
post
Sort of! I mean the author is the determining factor in nurturing along existing stuff, more than generating it. The models can accumulate context and get amazing at generating, but for someone not already aware of how to maintain, it's probably better to just keep making new versions from scratch
comment in response to
post
Like, most of our high-level symbols and structures in code are about maintenance, not instruction, you know? The actual whole field of PL design is about marrying provable concepts to feedback systems. None of that has expression in generative models right now
comment in response to
post
Being a rando here but, I think the primitives for maintenance are similar but the act of maintaining has a much harder critical path here, and it's much more firmly entrenched in programmer expertise. I think write-only is more or less here but curation is very, very far off / completely different.
comment in response to
post
Shoot, lol. Fair enough! Pardon my overthinking :)
comment in response to
post
Alright, I think I'm with you - so you're saying there's two contexts of usage here? The first is learning more about your limits and the way the systems work, and that informs the main goal, which is to bring that back to your actual WIP measurably with better grasp of your options?
comment in response to
post
I say "I know a lot of people who can code very well but I don't know a lot of people who care to" a lot.
I think this steps in the direction of broadening that, though, but I think the interaction metaphor, feedback loop, and ecosystem are still context-heavy in programmer-ese, I guess?
comment in response to
post
Honestly, I think if you can throw away the artifacts when you need to change them, "personalized" code is here - but I think that last mile of bridging it to non-programmers is still bigger than we imagine.
(There's other stuff. I really meant "big topic" there, haha)
comment in response to
post
Oh interesting. I'll be honest, it took a minute to digest the idea, even though I've been expecting to hear something like "LLM OS" for a few years now
What do you mean by shapes? Are we talking stuff like "background service agents" or something lower level?
comment in response to
post
How'd you validate it / proof it after it finished?
comment in response to
post
"Ah shit I forgot to call it by the fancy name on page 7, I just say 'do the thingy'. I'm ruined"
comment in response to
post
I bet you behind closed doors these people just call this shit something normal and they just don't want to put it in a paper or whatever because they're worried they'll get publicly mocked by other category theory pros.
comment in response to
post
Ah it's just a denotation of the unique homomorphism from an initial algebra into some other algebra; of course.
comment in response to
post
"Words mean things" sure but we make 'em up. Do a little cooking, idk.
Try to explain it to anyone non-technical except without a whiteboard and a computer. See what you come up with and go from there.
comment in response to
post
"It's a hard concept" okay, yeah. It is.
Now that you've got a grip on it, what made it hard to learn? Was it the idea or the lingo? Is there a way to maybe fix that for someone else? Is the lingo useful to you now? How? Is it better when talking to other people who use the lingo? Or, broadly?
comment in response to
post
Nobody gets in the way of programmers quite like programmers get in the way of programmers.
comment in response to
post
it's my productivity cloud and it's classy
comment in response to
post
Did you catch this? bsky.app/profile/angi...
comment in response to
post
I think "the primitives we need to operate async models" are really, REALLY close to "the primitives we need to orchestrate arbitrary models", which are really close to "the primitives we need to do this work with small, local models".
comment in response to
post
Stuff like this is on my "direction of generative models" checklist I keep in my head. They could definitely rig it fast!
I imagine it's a tricky dance for these orgs because a few of these moves highlight that you kinda want a bunch of tiny models orchestrated together, vs jumbo as-a-service ones.
comment in response to
post
100% - I've heard "programming with extra steps" echoing in my head a lot as I've played with all this, tbh
I guess I'm not convinced that the code is worth keeping, I suppose? That's a big topic
The actual payoff for me is what you're saying, a feedback process that forces you to model thoroughly
comment in response to
post
Yeah. My payoff in a lot of this is a quicker route to clarity, especially in areas where I don't even know enough to do a cold start. I'm still actually doing more or less all the code myself b/c I usually have to rewrite to read.
What are you working on? Are you able / willing to get into it?
comment in response to
post
I've hit a space several times in the last few weeks where I've had to coach a model through some (pretty tough: async distributed state) concepts in a clear enough way that it could use the instruction. I think this is probably in support of what you're saying.
comment in response to
post
I recently had to disentangle an inheritance on either side of a factory / builder / concretion chain of collaborators. I started to count the bounces between files to see what was actually causing each effect, sometimes counting past 12 file bounces for basic stuff like date format fns. Nightmares!
comment in response to
post
Wowwww
comment in response to
post
Wow I can’t decide which would be worse, between whether they knew who they were cold emailing or not.
comment in response to
post
But it’s been my experience that test setup remains, this just steers you to do it in a different shape. Like, you still hit points where the boilerplate gets onerous, but this makes you want to write formal kits for setup instead of doing something per file
comment in response to
post
The upside to this advice is that it’s easy to add and remove, you know? So you can add it over time if you want, and see how it works. Don’t have to change the test setup to put one here and there
comment in response to
post
Ouch. Mass produced factory assembled childhood experiences. :(