Live data from Hacker News

Difftastic: A diff that understands syntax

github.com

171–180 of 224 posts

Re: Difftastic: A diff that understands syntax

#171
post #14

Looks really cool, but there was no instructions on how to install it. I would recommend putting an installation guide in your readme, and it being a full installation guide. I followed the link to your manual and then it told me to install your tool using a tool called "cargo" with no reference on how to install cargo. At this point I gave up. Lazy, maybe, but for a convenience tool like this I want a convenient ins…

This method worked for me. No root required. https://news.ycombinator.com/item?id=30842720

Re: Difftastic: A diff that understands syntax

#172

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

So I looked at the paper and it seems interesting. Basic idea: Instead of the operations to consider being "insert", "delete" and "copy", one adds "reorder" "contract subtree" and "duplicate" (although I didn't quite get the subtlety of copy vs duplicate on a short skim); and even though extra ops increase the search space, they actually let you search more effectively. I can buy that argument. The practical problem,…

Some of the GHC performance bugs that we ran into during the research have been fixed as far as I know! Though I'd have to double-check

Re: Difftastic: A diff that understands syntax

#173
post #5

This looks absolutely amazing. One thing I do find interesting (and a wish were different) is that only programming languages are supported, rather than data formats as well. For example, two JSON documents may be valid but formatted slightly differently, or a common task for me is comparing two YAML files. Comparing config files that have a well defined syntax and or can be abstracted into a tree (JSON, YAML, TOML,…

Similarly, I would love it if Pandoc’s AST were supported. Or, if this could be extended to compare any documents taking formatting into account, or document-to-document conversions.

Re: Difftastic: A diff that understands syntax

#174

If you have consistent code style and formatting this tool is unnecessary. I think that solution is better, you get a more consistent code base that is easier to read for humans. (Also diffs will be faster to compute)

I run all python through `black` and `isort`; this is still a huge step up in my book in terms of readability and ergonomics compared to the standard `git diff` or gnu `diff`.

Re: Difftastic: A diff that understands syntax

#175

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

Should've named that repo "phdiff".

To be pronounced "Doctor-iff" in speech?

Re: Difftastic: A diff that understands syntax

#176
post #107

Earlier quoted context omitted.

I’d imagine there’s some challenging judgement calls that such a tool would have to make. Like, in Go, you can reorder the members of a struct definition. In many cases this is just diff noise to reviewers. HOWEVER, it does impact the layout of the struct in memory, so it can be semantically meaningful in performance work.

A wild nitpicker appears. I understand where you're coming from & why this matters. But Go, the language spec, doesn't make any guarantees about struct layout at all. A layout difference may be meaningful, practically, but it's potentially unreliable. e.g. see https://groups.google.com/g/golang-nuts/c/1BlZDNBLiAM Having said that: if a Go compiler for a given architecture decided to change its layout algorithm, I'm p…

PHP long stated that associative array sorting order was unstable and not guaranteed (especially when the union (+) operator or array_merge function were involved) - that doesn't mean ten bazillion websites wouldn't instantly break if they ever actually changed the ordering to be unpredictable.

Language designers need to contend with the fact that the ultimate final say in whether a thing is or not is whether that behavior is observed.

Re: Difftastic: A diff that understands syntax

#178
post #155

Earlier quoted context omitted.

> They can't be "in a different order" as JSON keys are not ordered. They can be whatever order, and would still be considered the same. This is what GP is saying, I'm pretty sure. Object member order is non-semantic in json, so in order to do a semantic diff (one that understands structure), you need to canonicalize the order of the two sides. Simply diffing the output of jq doesn't do that, because (afaik) jq doesn…

Just an FYI, jq has a flag to sort by the name of keys, I believe it's -k.

Fair enough! I should just never assume jq doesn't have a feature.

Re: Difftastic: A diff that understands syntax

#179
Checked out the repository.

Build instructions? Nope.

Minimum system requirements? Nope. But if you check out cargo.toml, you'll see it says it needs Rust 1.56.

My system has 1.48.0 . And it the latest Debian release! I don't see how a diff tool can expect you to have a bleeding-edge development environment. I mean, ok, you chose a new language - I can understand that; I won't demand that it build with just a C compiler and Make. But come on, this is not supposed to be just a toy for new systems.

Anyway, I still cloned it, tried to build with "cargo build", and got stuck with:

error: unexpected token: `include_str`

it couldn't even tell me "get Rust 1.56" :-(

Re: Difftastic: A diff that understands syntax

#180
post #122
post #107

Earlier quoted context omitted.

I’d imagine there’s some challenging judgement calls that such a tool would have to make. Like, in Go, you can reorder the members of a struct definition. In many cases this is just diff noise to reviewers. HOWEVER, it does impact the layout of the struct in memory, so it can be semantically meaningful in performance work.

I wrote a masters thesis about the more general problem here ( https://tspace.library.utoronto.ca/bitstream/1807/65616/11/Z... ). The tl;dr is that there's an almost infinite number of ways to atomize/conceptualize code into meaningful "units" (to "register" it, in my supervisor's words), and the most appropriate way to do that is largely perspectival — it depends on what you care about after the fact, and there is n…

I mean to have an improvement over the status quo we need to simply find a conception that works better than lines as units of code. Let’s not let perfect be the enemy of the good.
Post reply on HN