Hacker News Reader

Except languages are ambiguous. When you say you want to undo a commit, do you mean undo like pretend nothing had happened or undo but please keep track of the change.

That's why the first thing I do when I'm learning something new is to read the documentation to find out what capabilities are available.

Right away? Or when you actually need to do the thing?

When I start using anything new I really only check that it can do what I need it to, not everything that’s possible.

But those are two options of the same command. You can have a -keep-changes argument for undo and it wouldn't be weird or incompatible with the plain -language description.

> One way to look at Stackoverflow is that it's a gigantic index that maps "intuitive plain English" to "non-intuitive exact syntax".

It's not that syntax itself isn't intuitive; there's after all nothing more intuitive than, say, FORTH, LISP or Haskell syntax - surely it handily beats the weird idiosyncratics of "more English-like" FORTRAN or COBOL! It's actually the semantics of what you're interacting with, that, while simple, might be initially unintuitive to a naïve user. I don't think that I'm actually disagreeing with what you're saying; it's just that "not knowing the exact syntax for X" generally unpacks to something slightly different, namely "not knowing the relevant semantics to the extent that one can figure out how to do X". This, I think, is a better explanation of how StackOverflow might end up being quite helpful.

Of course, natural language itself does involve some semantics-related facets of its own, that might well end up being more intuitive than the programming-language semantics we normally use. But even then, we can (and should) use devices like Montague-semantics to give them an "intuitive", compositional syntax reminiscent of the lambda-calculus, Haskell or FORTH. I think this is the better way towards the goal of "using natural language to make programming more intuitive".

100% agree with this take. I mentioned it in another comment, but I've actually been working on a project which is essentially a better search engine for programming questions that's integrated in your IDE.

When possible, you try to pull out code snippets from SO/github/reference sites/etc that answer the query with high confidence. (Essentially like "instant answers" in google, but making it better by focusing on programming questions.)

The challenge is the level of noise and ambiguity that you get back in search results, and actually sorting through that to surface the right answers.

> "How do I undo a commit?" isn't something obvious like "git undo". Instead, it's the more cryptic "git reset HEAD~"[1]

The issue with this example is that `git reset HEAD~` doesn't undo anything, and it doesn't undo _any_ commit, just the last one. It will also cause push and merge conflicts if the commit you're "undoing" was public, which may end up with you not really having "undoing" anything at all.

It's also not anymore cryptic than any other industry's jargon. It's a sentence that means something specific. It's somewhat, but not entirely, what someone _could_ mean when they say "undo a commit".

>The issue with this example is that `git reset HEAD~` doesn't undo anything, and it doesn't undo _any_ commit, just the last one.

I shortened the question in my comment for brevity. The full question I cited on StackOverflow was worded as: "How do I undo the most recent local commits in Git?"

> It will also cause push and merge conflicts if the commit you're "undoing" was public,

Yes, and StackOverflow answers also warned of that scenario. Again, the full SO question did ask about "_local_ commits".

>It's also not anymore cryptic than any other industry's jargon.

In my comment, "cryptic" doesn't mean the syntax doesn't have its own internal logic that makes sense once one "groks it". It's just non-intuitive for someone who has a goal in their head but the only know plain English for describing that goal.

I know what the SO question said, but this hilights the problem with natural language: it isn't an unreasonable answer to "how do i undo a commit" and is infact a top result for that very search string in ddg and Google for me.

> Yes, and StackOverflow answers also warned of that scenario.

So the answer isn't git reset, but git reset + a whole lot more natural language, even for the more narrow question asked.

> In my comment, "cryptic" doesn't mean the syntax doesn't have its own internal logic that makes sense once one "groks it". It's just non-intuitive for someone who has a goal in their head but the only know plain English for describing that goal.

Isn't the true of anything? Everything has their own jargon to express precisely what they mean. Would you tell machinist they're being cryptic if they told you to make a bolt-hole pattern? Is an accountant cryptic if they talk about something being a liability and not an asset? A ham if they ask for fsk31 and to call them on 6m? Complex things require precise language to talk about precisely. That isn't being cryptic, it's a feature of natural language that it becomes more ridgid and precise with a specialized vocabulary when things require it.

>So the answer isn't git reset, but git reset + a whole lot more natural language, even for the more narrow question asked.

Yes, and like you confirmed, all of that was in the SO answers. I'm not exactly sure what you're debating here. I deliberately put an abbreviated SO question (some words elided) in my parent comment. I also put an abbreviated answer (some words elided). I cited the full SO answers that explained all the caveats, qualifications, in a footnote. Are you complaining that I didn't copy & paste the entire ~5000 words of StackOverflow answers into my comment instead of just typing "git reset"?

>Isn't the true of anything?

Yes! And that truism is why StackOverflow is so useful.

I think the root issue is that you think I'm making a claim I didn't actually make. I never claimed that natural language English is good enough for precise programming or that it didn't have ambiguities. I also think you misunderstood my blurb about git as if I was making an all-encompassing definitive answer for "git undo" instead of using it as a lead-in to a larger point about the tool discussed in this thread.

To hopefully convince you I know what you're talking about, we can also say that non-English programming languages themselves are also fuzzy and imprecise when trying to translate to another programming language. There's always a hidden underlying semantic layer that's not visible in the surface-level text of the code. E.g. converting Javascript to C++.

  Javascript:  var x = y + z;

But numbers in Javascript are always 64bit doubles. But we don't know if the programmer truly used them as doubles or whether all the runtime values were actually 32bit integers. That hidden semantic layer requires more analysis.

Therefore we don't know if the correct translation to C/C++ is:

  int x = y + z;

... or ...

  double x = y + z;

So even trying to perfectly translate non-English programminglanguage_A to non-English programminglanguage_B runs into The Halting Problem.

Here's the key, even though programming language conversion is imperfect, the programmers still have a real-world need to translate them and that's why Google and StackOverflow are useful for attempting to convert Javascript to C++.[1] Again to emphasize: Not perfect, but useful.

You seem to be working bottom-up from some Platonic ideal of perfect precision. My parent comment was working backward from the existence of thousands of real-world questions on StackOverflow that translates natural (sometimes fuzzy) English to non-obvious answers about syntax. It's about why do those Git questions exist and why were they useful. The tool that this thread is about takes advantage of that phenomenon.

[1] https://www.google.com/search?q=C%2B%2B+for+javascript+progr...

I agree that a lot of the unremovable difficulty in programming is translating natural English into something precise.

But I also think git often makes the problem worse by splitting similar operations unnaturally across different commands. I believe that was the motivation behind mercurial.

I thought git and hg both started around the same time, didn't they?

Yes, within days.

Ah okay. But still, hg vs git is a good example of doing the same things, but (the former) dividing the functionality along more natural boundaries. You still have the unavoidable complexity of defining precisely what you mean by "reverting" a change, but hg (from all I've heard) is more intuitive.