partdavid

I'm extremely interested in pushing along these fronts even in a performative way, because I don't want to get bogged down in "switch away from Emacs" conversations with coworkers. I've done a lot of modernizing on my Emacs setup this year but I would love a current take on "getting close to cursor" that gets me beyond what I'd had set up with copilot and lsp.

Since the jargon we've invented in technology has derived from natural language, it's often repurposing common terms as terms of art. In my opinion this leads to ambiguity and I sometimes pine for the abstruse but more precise jargon from classical languages you can use in medicine (for example).

For example, how many things does "link" mean? "Process"? "Type"? "Local"? It makes people (e.g., non-technical people) think that they understand what I mean when I talk about these things but sometimes they do and sometimes they don't. Sometimes we use it in a colloquial sense, but sometimes we'd like to use it in a strict technical sense. Sometimes we can invent a new, precise term like "hyperlink" or "codec" but as often as not it fails to gain traction ("hyperlink" is outdated).

That's one reason we get a lot of acronyms, too. They're too unconversational but they can at least signal we're talking about something specific and rigorous rather than loose.

Can you say more about which prior art you think overlaps here? We have a similar use case to Figma and are implementing a similar solution. I'm not particularly concerned whether the path we're following is novel but I am particularly concerned with whether there are gotchas along it that we should be watching out for, so if there are more mature solutions, we'd be interested.

I think you're agreeing with GP, not disagreeing.

I'm assuming "crash"--it's a mild malapropism based on some varieties of English phonetics that I've seen before.

I get what you're saying, but what's interesting to me is that this case is a mild signal that a subsequent developer could take the same erroneous implication. "Id" does in fact imply to me that entries are indexed by "Id", i.e., an attribute of the item being indexed, and that they are not array-like, in that they wouldn't all get different IDs by a deletion, for example.

Accusations are often confessions.

The shallow analogy is like "why worry about not being able to do arithmetic without a calculator"? Like... the dev of the future just won't need it.

I feel like programming has become increasingly specialized and even before AI tool explosion, it's way more possible to be ignorant of an enormous amount of "computing" than it used to be. I feel like a lot of "full stack" developers only understand things to the margin of their frameworks but above and below it they kind of barely know how a computer works or what different wire protocols actually are or what an OS might actually do at a lower level. Let alone the context in which in application sits beyond let's say, a level above a kubernetes pod and a kind of trial-end-error approach to poking at some YAML templates.

Do we all need to know about processor architectures and microcode and L2 caches and paging and OS distributions and system software and installers and openssl engines and how to make sure you have the one that uses native instructions and TCP packets and envoy and controllers and raft systems and topic partitions and cloud IAM and CDN and DNS? Since that's not the case--nearly everyone has vast areas of ignorance yet still does a bunch of stuff--it's harder to sell the idea that whatever AI tools are doing that we lose skills in will somehow vaguely matter in the future.

I kind of miss when you had to know a little of everything and it also seemed like "a little bit" was a bigger slice of what there was to know. Now you talk to people who use a different framework in your own language and you feel like you're talking to deep specialists whose concerns you can barely understand the existence of, let alone have an opinion on.

I've done okay with copilot as a very smart autocomplete on: a) very typical codebase, with b) lots of boilerplate, where c) I'm not terribly familiar with the languages and frameworks, which are d) very, very popular but e) I don't really like, so I'm not particularly motivated to become familiar with them. I'm not a frontend developer, I don't like it, but I'm in a position now where I need to do frontend things with a verbose Typescript/React application which is not interesting from a technical point of view (good product, it's just not good because it has an interesting or demanding front end). Copilot (I use Emacs, so cursor is a non-starter, but copilot-mode works very well for Typescript) has been pretty invaluable to just sort of slogging through stuff.

For everything else, I think you're right, and actually the dialog-oriented method is way better. If I learn an approach and apply some general example from ChatGPT, but I do the typing and implementation myself so I need to understand what I'm doing, I'm actually leveling up and I know what I'm finished with. If I weren't "experienced", I'd worry about what it was doing to my critical thinking skills, but I know enough about learning on my own at this point to know I'm doing something.

I'm not interested in vibe coding at all--it seems like a one-way process to automate what was already not the hard part of software engineering; generating tutorial-level initial implementations. Just more scaffolding that eventually needs to be cleared away.

A non-forking prompt command is an absolute requirement for me and always has been, so I did this in pure shell. It's not a lot of code but it's a little tricksy.

If I still used bash, starship would be a non-starter for me, in part, since it's fork/execed in the prompt command. Further up this thread someone says that the zsh installation is different and it's a native shared library that gets loaded into zsh. That seems neat.

(The other reason it's a non-starter is that maybe I can stomach sending over a dotfile to various systems, but selecting a platform-specific native binary is too much configuration management to be done to prepare for an SSH session/kubectl exec. Eventually I made my peace with doing this for emacsclient so I could have local editing of remote files, but that's a lot less critical of a piece to miss than something that appears in your prompt. Conceptually, if you want to ship over/config-manage a native binary, you might as well install a better shell, which became a compelling argument to me when I switched to Powershell).

My earliest background as a shell user was as as system administrator (back in "the day", let's say), and forks are always potentially expensive, and often the reason you're opening a shell session in the first place (to diagnose resource contention or exhaustion, for example). There have been lots of times when one more fork is too much to take. (Which also, yes, makes it "interesting" to figure out what you can run in your shell session, too).

It strikes me as very much a current aesthetic in younger companies or smaller startups, maybe highly influenced by Notion. No one makes a list or page or calendar invite in my current company without choosing an emoji for it.

I suppose (strictly speaking it's easier to C-x o into the terminal frame or Alt-tab to the terminal window; but it's negligble either way), but the "cost" is not really about invoking it, but learning it for an unclear payoff. Everything is different for me in dired window, navigation doesn't work the way it does in a text buffer, you have to drill down and up in steps.

On the occasion where I'm even tempted to interact with a list of files, it seems easier to do

  git diff development --name-only | gci | ocgv | sco -exp fullname | xargs e

And then pick from the list and boom, they're all in buffers. I mean, sure, that's because I set it up that way (in particular the emacsclient wrapper e, which does other smart things like find the TRAMP server, etc. etc.), and presumably there's an equivalent in dired but the distance from here to there seems paved with a lot of clunkiness. The nice thing about using the shell is that I can add to or subtract from these expressions and manipulations at will.

I'm also an emacs user in the habit of using the shell for file management, and I just deal with this mismatch. It hasn't been annoying enough for me to solve by switching to something else. But then again, I guess I don't do a lot "file management", whatever that really means.

It sounds right, and this is the kind of thing I'd expect if developers are baking configuration into their app distribution. Like, you'd want usage rules or tracking plugins to be timely, and they didn't figure out how to check and distribute configurations in that way without a new app build.

We have already been through some generations of this rediscovery an I've worked at places where graphql type importing, protobuf stub generation etc. all worked in just the same way. There's a post elsewhere on HN today about how awesome it is to put your logic _in the database_ which I remember at least two generations of, in the document DB era as well as the relational era.

If there's one thing I've observed about developers in general, it's that they'd rather build than learn.

My Boox is pretty crap. My use case is Libby for library books and the display refreshing and other things make it almost unusable. Feels super cheap, unsupported.

The rulebooks (or videos) as well, do often omit this.

But even when the overall goal is either obvious or explicitly stated, it's very common for none of the described options or actions to provide a motivation for the action or option that connects to the goal.

In other words--yes, I can read some rules that say "on your turn, you can draw a BLANKLY card, play a FARB token, or advance one of your MORTGAGED BULLETS on the community barrel."

But why would I do those things? So many rulesets could improved by adding motivation, like "If you think an opponent that owns your MORTGAGE is getting to close to the BULLETPROOF PIT, then you can beat them to the pit by advanced a MORTGAGED BULLET toward the target." Ah! Okay, those are the circumstances under which I might want to do that.

Or, "If you aren't getting enough FARB tokens to block opponents, you might need more of the FARB-earning resources you can get by drawing BLANKLY cards. Remember that you're trying to either build a ROBOT--using parts on some of the FARB tokens--or destroy others' ability to build ROBOTs by shooting them."

The rules of the game aren't really "how you play"; and a newcomer doesn't have a playstyle. You need to mix the basic strategy with the rules instead of just giving a bunch of options and no pointers as to why you might want to do one thing over another.

Because it's attempting mythisimilitude, not verisimilitude.

How does this replicate Postgres data? I glanced at the code and saw that it exports to a CSV file then writes out an Iceberg table for an initial snapshot--does it use Postgres logical replication?

And not just restricted to English; it's a very common experience in the U.S. for native speakers of, e.g. Spanish, to end up in Spanish-language courses with non-native Spanish teachers, with modest Spanish skills. I assume it's the case with all language teachers especially at a non-advanced level.

Yeah, it's hard to do a direct comparison, because bash needs a bunch of other utilities to be useful and they also take up space. In theory you can pick and choose but woe be to you if you want to use bash without sed, awk, cut, etc.

But it's true that, like, you get help with Powershell but that might not matter on a system where you wouldn't choose to install man pages or something.

Oh, it's not dismissive at all. It's not just a real consideration, it's an overriding one. I switched my "daily driver" shell to powershell but I still write CI/CD scripts in bash, and docker entrypoints, and cloud-init userdata, and utilities, because it's niche enough to be too much to ask my coworkers and community folks to also switch.

I do wonder about the muscle memory thing. I think having to create scripts in bash keeps my hand in enough that I won't lose it too badly. At least I hope so. I compared switching shells to switching keyboard layouts; something I also did, and something where it's been some effort to retain enough muscle memory to not completely flail when presented with another computer.

Thanks, that makes a lot of sense. I can see a lot of similar cases especially for sysadmin things (systemctl, ifconfig, etc.).

One thing that was nice about my adopting Powershell as my daily shell is that for the most part, I could just use the same shell utilities as usual:

  getent passwd | cut -f6 -d':' | sort | uniq -c

Like, there's no problem running that in powershell. I know people have talked about "mixing" strings and objects but, I have to say that for me I've rarely run into a problem with it?

As you learn you can do a little more. Maybe you learn that group (group-object) can be used instead of the two commands at the end:

  getent passwd | cut -f6 -d':' | group

And for me, the nice thing is that when you learn something like that, it's leverageable across all your cases. You learned something about your tool, not just about the passwd file.

Is this better than bash? I don't think it's worse:

  getent passwd | %{ ($_ -split ':')[5] } | group

But then you might notice that your data is a CSV (C for colon in this case) and you might leverage some of the CSV-handling which works well in Powershell:

  getent passwd | convertfrom-csv -del ':' -h 'user','pwd','uid','gid','comment','home','shell' | group -prop 'shell'

Now you're cooking with structured data again. I think familiarity makes this kind of thing come naturally. And since these commands are pretty discoverable, because they're more consistent, and tab-completion and command-line editing are so much better than bash. It's easy to see how the above can be made terser by stashing it into utility function or a hashtable in your profile (e.g. so you could do "getent passwd | fields passwd" or something like that.

Now, I'm not going to tell someone it's worth the growing pains and adjustments to switch. It's like switching keyboard layouts. And matters of taste might turn you off, understandable. But for me there have been real benefits, and on its merits, I do think it makes a better shell. And it would be nice (from my perspective) if the community did some more work around these use cases and making them nicer for people.

I agree, this is a place where the desired features are in tension. I will say that it took me a while to find it, and I don't find it limiting now that I understand it, but it was a real gotcha when I encountered it.

I'm not sure I understand your point regarding having to look at the output of commands to know how to use them. At least with Powershell you have tab-completion suggesting your object members; you have to at least look at whatever flavor of semi-parsable text is coming from your command in bash to use cut or awk or whatever on it (and the semantics of what you're looking at are not discoverable, so you're likely to have to some API digging of your own). 'cut' and the like is sadly fragile for a number of reasons, and you generally won't discover them in advance (e.g. when the date "field" starts containing a year, sizes overflow or start being indicated with human-readable abbreviations after a threshold, which is exactly the sort of thing you can't tell by inspection). And bash's failure modes are really sharp.

To be honest, something like

  $titled = gci *.md| ?{ (gc $_)[0] -like '# *' }

seems short and less error-prone than the bash equivalent. Not sure what it would be. Something like

  titled=(); for file in *.md; do if head -1 "${file}" | grep -sq '^# .*'; then titled+=("${file}"); fi; done

I think there's a lot of little gotchas in there, and not a little "API digging" for options, though it's simple in concept.

This is the opposite of how I see it. There's really nothing universal about flags, especially short ones, in different random utilities (what's -n mean? -f? file, filter or force?). Whereas in Powershell since there actually is some standardization, your knowledge about what -WhatIf or -Verbose do is actually pretty leverageable. And more powerful with the ability set default parameters and so forth. And the discoverability and help in Powershell is also standardized.

So I get why unfamiliarity would make it not worth it to switch from whatever shell you prefer, but I don't think I can see your point about flags.

For what it's worth, I've had the opposite experience, maybe because I work in a different domain. Personally, I still think using Powershell functions and treating lines as string objects is an improvement over bash and its mini-languages, anyway; and most standard Unix commands have Powershell close equivalents. Some Powershell expressions might be abstruse but so is, say, awk; but when you've learned awk you only know awk; whereas the Powershell technique you used (calculated fields in select-object, for example) is permanently useful. I do spend a lot of my time with various random APIs so Powershell is pretty joyful compared to (say) curl/jq or yq-ish stuff. There was a real adjustment period, of course, getting used to a new shell; but it was the best thing about my experiment with Windows (discovering a new shell that I now use on my Unix-like systems, because I did not end up wanting to adopt Windows).

So I'm curious what kinds of things you mean when you say you have to parse everything as text anyway. I suspect you've needed to a lot more of those kinds of tasks than I have.

Many takes in this thread are people not realizing this and having a really narrow view of what people are shaving, and why, and what might or might not work for them--inappropriately generalizing their own constraints and desires to others.

It would be awfully nice to have, or just a functional hcl2json that you can actually use, and doesn't barf on very common cases. Introspecting Terraform (or another HCL language) is something I've often wanted to do and support is very poor. Ideally Terraform would actually do this (produce an intermediate parse in JSON or something) but it doesn't. But there are a lot of cases where you want to examine such a manifest and derive information from it.