Oh yeah, the 365 version is terrible. And post of the time, it could have been a Python Gradio interface or similar simple implementation without having to fight so much to make basic things work. Most of what I want Excel to do it just isn’t efficient enough for; particularly with lets and lambdas, it’s gotten quite powerful as a programming paradigm where you can visualize and manipulate your data spatially in a kind of Logo / NetLogo style way which is really interesting, but the second you reference a few thousand cells a few times even a solid CPU starts screaming.

I use Excel for a decent number of tasks and can do some magic with it, but only ever really for work where it’s easier to share a weird Excel sheet than it is to pass around a Python script (which given I teach Python, isn’t actually as often as most people experience).

But what about those of us in R1C1 mode using lambdas to do recursive cell operations across data pulled from multiple sheets? Am I anywhere near the kinda of Eldritch horrors discussed? I’ve also written indirect references based on Sheet name to populate filters from web scraped tables. I just don’t know how deep the pit goes at this point.

Yeah, I wasn’t a fan of the visual scripting, but I do consider composing nodes in the editor, connecting signals, modifying field values with sliders, having global variables in a separate editor, visual curve editors, file managers, etc. to be a form of visual scripting by a different name, and I do quite like that.

I’ve been curious how this sort of editor would work for non-game code, like making a CLI in C, C++, Kotlin, etc. Where you primarily interact with nodes and inspectors for data organization and scripts for behaviour implementation. I need to go back to Smalltalk to see some of the ideas there for alternative code organization structures.

Maybe I’m an old fogey, but I usually hear more pushback against visual languages as being too finicky to actually create anything with and I usually advocate for a blending of them, like working in Godot and having nodes to organize behaviour but written scripts to implement it.

I really appreciate the talks from Bret Victor, like Inventing on Principle (https://youtu.be/PUv66718DII), where he makes some great points about what sorts of things our tooling, in addition to the language, could do to offload some of the cognitive load while coding. I think it’s a great direction to be thinking, where it’s feasible anyways.

Also, one reason folks new to programming at least struggle with text code is that they don’t have the patterns built up. When you’re experienced and look at a block of code, you usually don’t see each keyword, you see the concept. You see a list comprehension in Python and instantly go “Oh it’s a filter”, or you see a nested loop and go “Oh it’s doing a row/column traversal of a 2d matrix”. A newbie just sees symbols and keywords and pieces each one together individually.

Not to fully argue against your point, but I do want to push back on the citations bit. Given the way an LLM is trained, it’s not really close to equivalent to me citing papers researched for a paper. That would be more akin to asking me to cite every piece of written or verbal media I’ve ever encountered as they all contributed in some small way to way that the words were formulated here.

Now, if specific data were injected into the prompt, or maybe if it was fine-tuned on a small subset of highly specific data, I would agree those should be cited as they are being accessed more verbatim. The whole “magic” of LLMs was that it needed to cross a threshold of data, combined with the attentional mechanism, and then the network was pretty suddenly able to maintain coherent sentences structure. It was only with loads of varied data from many different sources that this really emerged.