iterm2 has some options to fix key bind issues that hamper emacs in the terminal.

No source control, there's only 1 version of the software; the latest version (trunk based development).

The specific techniques used to send, receive, and parse JSON could matter.

Python's popularity is an accident of timing. If you're digging deep for wisdom and gold nuggets you're not going to find any. The gold of python is the surface level stuff. Easy to type for hunt-n-pec typers. Press tab to indent is easier than {}.

That's all it took for an army of noobs who wanted to be "hackers" to choose Python. Then they grew up, got real jobs and brought Python with them.

Younger people are more likely to accept orders without push back. Accept lower pay. Work 60+ hr/week for crunch time, etc.

Depends on the employer of course. Google employs an 80+ year old Ken Thompson.

So I'm reaching for Go for pretty much everything now days.

Find defs and refs. Master a little bit of regex and you will reduce false positives.

Grep serves as a rudimentary autocomplete. find the definition, open in a buffer, observe fields. This is analogous to an autocomplete popup displayed inline. The buffer can now power your contextual completions, similar to an inline popup.

Typescript let's you start with a cross platform GUI right out of the gate. Text based HTML GUI is screen reader friendly, battle hardened for many years to get accessibility right.

Type system is advanced and allows for that sweet IDE experience.

And.... the Javascript ecosystem is the only game in town that gets close to the Lisp immediate feedback experience. (no Javascript is not as good as a lisp image, but it's better than nothing). Change a function, see the result instantly in the browser while you're app is still running. I'm not 100% sure this is true for Typescript as it must compile to javascript first, but compiling the TypeScript for 1 modified file with an on-save-hook could still be a pretty quick feedback loop.

Do these reasons have anything to do with AI agents? no but it would explain why people are already using Typescirpt, and thus use it for AI agents.

That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory.

Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.

And there's a few cases like Print() where errors are so commonly ignored you don't even want to use the "_" ignore syntax. Go gives you the poetic license to avoid spamming underscores everywhere. error linters can be configured to handle a variety of strictness. For non-critical software, it's OK to YOLO your Print(). For human-death-on-failure software you may enforce 100% handling, not even allowing explicit ignore "_" (ie become even stricter than Rust language default)

A lot of tasks involve having context to produce a correct solution. AI can whip up algorithms in a vacuum. But doesn't know about the custom data format you have to import. It doesn't understand how to map that to the target schema and will blindly import in a way that is subtly wrong. It doesn't have the context provided by chit/chat and vague statements made in an email.

No matter how impressive AI works in a vacuum, the "context" heavy problems are going to be an issue. Someone mentioned "last mile", that's where things fall apart. Same with self driving, it is impressive at first, until a road is blocked and there's some poorly marked detour signs routing you through non-standard paths.

Same with a plumber. You might make a robot that can fix many plumbing problems. But there's always custom nooks and crannies you have to contort yourself into and saw off a pipe in a very specific way that only having a tons of context would let you even know where to begin.

So until AI can consume context the way humans can, it's going to be limited to a "auto completion on steroids". Which is valuable, but not the end of human developers. Only time will tell.

line 2: blank

line 3+: long description, paragraphs, details, context for decisions made, rambling

Convert the xlsx to csv. Every database system out there has blazing fast import of csv files.

As a sql wizard, I prefer to use sql to clean and re-shape data. So my first goal is to get the data into a sql DB as quickly as possible, no cleaning, no re-shaping. Just a raw dump. Now the data is in my house. I clean and re-shape the data with batch update/insert statements. Finally I batch insert to the target tables.

> what’s the most frustrating

Every import job is a custom scenario. I feel special tools don't give you much. You have to understand both the source and destination data to clean and re-shape it. Tools don't have that understanding. AI is less than worthless. At the end of the day you have to roll up your sleeves and start shaping data.

Work in a feature branch. Commit often. Squash away the junk commits at the end.

> ...and especially good enough to have a title.

Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor.

I treat commits in a private branch the same as the undo log of the text editor. No one cares about the undo log of your editor as they never see it. The same should be true of your private feature branch commits. They are squashed away never to be seen by human eyes again.