Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How far should a programming language aware diff go?

semanticdiff.com

Post reply on HN
Print view View original

11–20 of 54 posts

Re: How far should a programming language aware diff go?

#11

Post by egnehots »

culi wrote: post #9
kmoser wrote: post #5

> - const foo = function(a, b) { ... } > + const foo = (a, b) => { ... } Assuming this is JS code, these differences should not be ignored, as an arrow function can behave differently than a traditional function.

More specifically, the `function` keyword version of an anonymous function preserves the keyword `this` whilst the arrow syntax anonymous function does not. Arrow functions also cannot use the `yield` keyword nor be used as constructors https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

There is also the function scope vs block scope...

var x = 3 will escape the latter.

Re: How far should a programming language aware diff go?

#12

Post by Smaug123 »

g4zj wrote: post #6

I've never knowingly used a language-aware diff tool before, but I wouldn't mind the option. I think it would come in handy on occasion.

Personally I have `git difft` aliased to `difft --display side-by-side`, so it's one extra character for a semantic diffing tool (for me, Difftastic).

Re: How far should a programming language aware diff go?

#13

Post by glhaynes »

kmoser wrote: post #5

> - const foo = function(a, b) { ... } > + const foo = (a, b) => { ... } Assuming this is JS code, these differences should not be ignored, as an arrow function can behave differently than a traditional function.

My guess would be that quite a large portion of changes we'd expect at a glance to be identical aren't, especially for inputs that would not be expected. I'd also guess this is much more likely in languages in which valid code commonly produces undefined behavior.

If the tool could show you, for example, "this change is functionally identical except for when the sum of the two inputs overflows a UInt64", that'd be pretty cool.

Re: How far should a programming language aware diff go?

#14

Post by 1-more »

Smaug123 wrote: post #12
g4zj wrote: post #6

I've never knowingly used a language-aware diff tool before, but I wouldn't mind the option. I think it would come in handy on occasion.

Personally I have `git difft` aliased to `difft --display side-by-side`, so it's one extra character for a semantic diffing tool (for me, Difftastic).

Because I am silly I have

    dit () {
        verb="$1"
        shift 1
        GIT_EXTERNAL_DIFF=difft git $verb --ext-diff $@
    }
it works for `dit d` and `dit show HEAD` but it fails on `dit stash show -p stash@{0}`

Re: How far should a programming language aware diff go?

#15

Post by rob74 »

I think I have heard of their product before, and reading the blog post intrigued me, so I wanted to try it, but... VS Code Integration? GitHub Integration? No standalone version which you could actually use as a diff tool for git locally? Ok, I guess only having a "cloud" version makes licensing easier, and you can call me old fashioned, but seeing an eminently "offline" task such as diff being turned into "online-only" seems a bit strange to me.

Re: How far should a programming language aware diff go?

#16

Post by culi »

egnehots wrote: post #11
culi wrote: post #9

Earlier quoted context omitted.

More specifically, the `function` keyword version of an anonymous function preserves the keyword `this` whilst the arrow syntax anonymous function does not. Arrow functions also cannot use the `yield` keyword nor be used as constructors https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

There is also the function scope vs block scope... var x = 3 will escape the latter.

I believe this is actually a difference between named and anonymous functions. The named function syntax is

  function foo1() { ... }
Both of the below examples are anonymous functions

  const foo2 = function() { ... }

  const foo3 = () => { ... }

Re: How far should a programming language aware diff go?

#17

Post by culi »

glhaynes wrote: post #13
kmoser wrote: post #5

> - const foo = function(a, b) { ... } > + const foo = (a, b) => { ... } Assuming this is JS code, these differences should not be ignored, as an arrow function can behave differently than a traditional function.

My guess would be that quite a large portion of changes we'd expect at a glance to be identical aren't, especially for inputs that would not be expected. I'd also guess this is much more likely in languages in which valid code commonly produces undefined behavior. If the tool could show you, for example, "this change is functionally identical except for when the sum of the two inputs overflows a UInt64", that'd be pr…

I think you've answered the question posed by the title here. That's feels too far

Re: How far should a programming language aware diff go?

#18

Post by g4zj »

Smaug123 wrote: post #12
g4zj wrote: post #6

I've never knowingly used a language-aware diff tool before, but I wouldn't mind the option. I think it would come in handy on occasion.

Personally I have `git difft` aliased to `difft --display side-by-side`, so it's one extra character for a semantic diffing tool (for me, Difftastic).

Thanks for mentioning Difftastic. It looks very interesting! I'll give it a try.

Re: How far should a programming language aware diff go?

#20

Post by kmoser »

glhaynes wrote: post #13
kmoser wrote: post #5

> - const foo = function(a, b) { ... } > + const foo = (a, b) => { ... } Assuming this is JS code, these differences should not be ignored, as an arrow function can behave differently than a traditional function.

My guess would be that quite a large portion of changes we'd expect at a glance to be identical aren't, especially for inputs that would not be expected. I'd also guess this is much more likely in languages in which valid code commonly produces undefined behavior. If the tool could show you, for example, "this change is functionally identical except for when the sum of the two inputs overflows a UInt64", that'd be pr…

That would neat, although I suspect most compilers/linters should already be able to warn you about potential overflows.

If you want to boil down what devs are looking for in a diff tool to one thing, it would be "which change(s) between these two versions of code result in a different binary (or AST/opcodes/bytecode, depending on the language)?" All other changes, while certainly sometimes useful to know about, are just syntactic sugar.

Post reply on HN