Right. All it takes is for one to work out, if you have several suitable options. If some of the options are only vaguely suitable, or it comes to light through the process that some of them are not suitable at all, then it takes more than just one working out. That's what I was thinking while reading this.
Originally open-source, but since taken back in-house. As I understand, which should not be construed as an accurate accounting, Sandia wants to flesh out the basics further before (potentially) open-sourcing it again.
> So much of writing is managing your own emotions. The virtue of “pseudowriting” is that it helps you preserve hope for as long as possible—hope that what you will eventually put in place of those square brackets will be good. Hope keeps you coming back: it is more pleasant and low-stakes to pseudowrite than to fix actual language into the draft; and it is less daunting to return to a document where it feels like all that’s left is for you to fill in some blanks. Do that enough times and you will, in fact, end up with something you can read top to bottom.
This describes how I write a new chunk of research code, often. I'll type along until I get to something like "oh, I'll need to calculate the foo of the widget here," and I'll just put a non-existent function call calculateFoo(widget) there until later, when I'll come back and fill it in. I feel like it keeps it manageable; I'm choosing the level of abstraction that I'm drafting code at, and I come in and fill in the details later. I hadn't connected this idea to the journal articles that I am working on; I typically feel somewhat guilty when I add a FIXME in my LaTex document, but with this framing I see now that that is probably the better way to do it than aiming for a finished paragraph from the get-go. The square brackets and placeholders also seem much nicer that the FIXME I was using. Glad to have seen this at a timely moment for me!
I didn't have time to get through the whole article today, but I did spend some time with my kids playing the Wikipedia first link game, which we enjoyed. We kept trying to find one that didn't end in Philosophy, and my youngest son said we should try Brick. Sure enough, it ended in a loop consisting of Existence and Reality.
My brother just finished building an automatic pipe organ for his Mechanical Engineering senior project. Or maybe you'd call it a street organ since it has no keyboard. It has midi input on some arduino-like device, 3d printed pipes, a hand crank pump to fill the bellows, and a bunch of shift registers, relays, and solenoids (on breadboards at this point) to open the valves for the pipes. It turned out really nice, and was a hit at the project showcase. I was involved in helping him figure out the electronics and the code, though I think he threw out the code I wrote in favor of using ChatGPT. All in all, it's not a technically difficult thing to make, though I have the benefit of his hindsight at this point. Maybe I'll get him to write it up at some point.
I'm the kind of guy who decently likes maps, and I pay attention to where I'm going and also to the map before, during, and after using a GPS (Google maps). I do benefit from Google maps in learning my way around a place. It depends on how you use it. So if people use LLMs to code without trying to learn from it and just copy and paste, then yeah, they're not going to learn the skills themselves. But if they are paying attention to the answers they are getting from the LLMs, adjusting things themselves, etc. then they should be able to learn from that as well as they can from online code snippets, modulus the (however occasional) bad examples from the LLM.
> I do benefit from Google maps in learning my way around a place.
Tangent: I once got into a discussion with a friend who was surprised I had the map (on a car dashboard display) locked to North-is-up instead of relative to the car's direction of travel.
I agreed that it's less-convenient for relative turn decisions, but rationalized that setting as making it easier to learn the route's correspondence to the map, and where it passed relative to other landmarks beyond visual sight. (The issue of knowing whether the upcoming turn was left-or-right was addressed by the audio guidance portion.)
It's neat to hear that I'm not the only one who does this. It makes a night-and-day difference for me.
When the map is locked north, I'm always aware of my location within the larger area, even when driving somewhere completely new.
Without it, I could never develop any associations between what I'm seeing outside the windshield and a geospatial location unless I was already familiar with the area.
I'm not extremely familiar with the details of incremental parsing, but I have used Cursorless, a VSCode extension based on tree-sitter for voice controlled structured editing, and it is pretty powerful. You can use the structured editing when you want and also normal editing in between. Occasionally the parser will get things wrong and only change/take/select part of a function or what have you, but in general it's very useful, and I tend to miss it now that I am no longer voice coding much. I seem to remember that there was a similar extension for emacs (sans voice control). treemacs, or something? Anyone used that?
If you’re discussing large groups of people, you have to somehow compress the data. On the other hand, yeah, you probably shouldn’t prefer things like this to explain your neighbor/friend/in-laws over personal interactions with them.
