let's see these guys implement diff

One of our clients fucked up some configs so I had to go in and fix it. Easy task right? Copy diff.exe, check fuckups, done. WRONG. First you have to find a differ.

Why is it impossible to write a good software, compile it to a single binary and be done with it. Why do we have to make everything so complicated. File1 left, file2 right, changes blue, additions green, removals red. Nobody needs a mongolian translation nor cool icons nor 3way compare. Fuckk off imbed the images and translations in the binary if you can't help yourself.

I went with a legacy version of some differ the newer versions come with 3 dlls, 20 translation files, a phat coc, a copy of 7zip and fucking cygwin and the newest version can't even be used without an installer.

FUCK SOFTWARE

install gnu diff

learn Hunt-McIlroy algorithm and lets see you implement diff

WSL

>>2
Inefficient for a human. Interpreting plain text is worse than having the two files side by side and the changes marked nicely.

>>4
I'm not going to install a complete operating system to get a plain text representation of a diff.

>>3
Maybe you're right.

Just upload it to github and use their diff.

>>1
Why didn't you implement diff yourself then?

smart diff
somehow twists huge changes into Cthonic transformation of source to patch to minimize the size of patch(which is irrelevant since 90's hard disks have progressed past 1 GB)

The dumber, large diffs(removes changed lines) are far easier to read and reason about.

>>8
No one even said that!

>>9
Perhaps it would be easier to read and reason about if you mentally substitute email quotes to plain plain quotes?

"smart diff"
"somehow twists huge changes into Cthonic transformation of source to patch to minimize the size of patch(which is irrelevant since 90's hard disks have progressed past 1 GB)"

The dumber, large diffs(removes changed lines) are far easier to read and reason about.




The dumber, large diffs(removes changed lines) are far easier to read and reason about.

>>7
Someday I will admit my role.

Package managers de facto made us spoiled for hard-to-build shit. Like Chromium or Calibre. Jegus, even with traditional package managers. I pray to a picture of RMS's taint every day that Guix comes into fruition so I don't have to deal with that anymore.

Notwithstanding, isn't diff POSIX compulsory? Call me a weenie, but I feel like issues such as this are what UNIX's all about. Grep may not do everything, but everything has grep. You can always write a script for grep; whereas, were you to reinvent the wheel with Python or whatever, you need libraries, and the end result may be too inscrutable for its worth. UNIX may not be super meritocratic, but that is practical.

>>12

You can always write a script for grep; whereas, were you to reinvent the wheel with Python or whatever, you need libraries, and the end result may be too inscrutable for its worth.

FIOC has good enough text-processing tools in its stdlib. not as many as Perl, but arguably much more readable. Unless your're are talking about Python itself needing libraries - that's true, and I'd argue there's a cut-off point (either with performance or with complexity) before which you should use *nix tools and after which you should switch to an actual language.

for example, I once needed to write a tool which processed a lot of Smali files (disassembled Android bytecode). the initial quick-and-dirty version was a grep-heavy portable shell script, but it was difficult to add functionality to it, and on larger projects (larger as in 'after disassembling literally all the code you have on a modern phone') it would take over half an hour to run. I rewrote it in Java 8 (don't judge, it offered a decent speed - unlike scripting langs - without the need to reinvent the wheel of text processing - as in C; I guess I could have done it in sepples, but I'd argue Java is the lesser evil here) and it took less than a minute.

Unless your're are talking about Python itself needing
libraries

I meant both, I guess. libs in Python for more applications than just parsing text, which aren't trustworthy (especially for the Python audience) or well-tested; the latter, I actually had an experience recently for OpenWRT where this was the case in that there was this Python script for StevenBlack's hosts, and I ended up writing a simple shell script in lieu of that. I don't even know why that script exists. You're literally just fetching the latest hosts file, appending your blacklist and expunging stuff corresponding to your whitelist. Why invoke Python? especially when OpenWRT, an obvious demographic for that script, doesn't ship with Python. I mean, it only took a minute, but it was weird and dumb.

the initial quick-and-dirty version was a grep-heavy
portable shell script, but it was difficult to add functionality to it

When I was writing my post I was actually thinking about awk while I was writing about grep, but I neglected to mention it. It's kind of funny, isn't it, though? awk is more powerful than grep, but I don't even know if it would scale to your scenario. Both of them are pretty good examples of the more minimalist UNIX programs, and yet, despite being really simple, they simply don't have the longevity that one should expect for their simplicity, nor the generality. They represent specific scopes of use, so it's easy to overlook an intermediate tool like awk.

Having these little programs with their own simple but unique interaction paradigms detailed in a man page seems like an okay idea until you need to rely on it. Youtube-dl is a good example, because its config and its triggers don't 100% match up, which leaves me scratching me head sometimes, and I imagine it's even tougher to comprehend as a novice user. But the alternative is equally as horrifying: this Python package, beets, is great, but it's extended in yaml, and it's absolutely terrible. I mean, just awful. What ended up happening, initially, is that I just end up writing wrappers in bash for all of them, which, ironically, is much more powerful than how they're conventionally configured. And then I switched to Elisp, because I just stopped caring. After all, there's only one true constant in this world: Emacs.

>>14

When I was writing my post I was actually thinking about awk while I was writing about grep, but I neglected to mention it. It's kind of funny, isn't it, though? awk is more powerful than grep, but I don't even know if it would scale to your scenario. Both of them are pretty good examples of the more minimalist UNIX programs, and yet, despite being really simple, they simply don't have the longevity that one should expect for their simplicity, nor the generality. They represent specific scopes of use, so it's easy to overlook an intermediate tool like awk.

I'm pretty sure awk would manage this (it would be slower than Java but faster thanr recursive grepping), but I gotta admit I just don't know how to do any serious programming in it. it's not the most user-friendly language, and I guess unlike many other languages that you'd need to invest time to feel comfortable in (e.g. Scheme, OCaml, even fucking Sepples) it really doesn't offer you that much (well, other than portable Unix text-processing)

this Python package, beets, is great, but it's extended in yaml, and it's absolutely terrible. I mean, just awful.

that's something I don't get. if you have a scripting language, why don't you expose whole thing as a library in that language (it's trivial to write a Python command-line program that is also a library)? inventing a yaml-base language when your're are already inside a better scriptlang is a pointless case of inner platform effect (see: https://thedailywtf.com/articles/The_Inner-Platform_Effect)

>>13
>I rewrote it in Java 8
sage

SAGE

fhoauhfoahflaksdjflawhfiluqgwripu SAGE

.oooooo..o
d8P' `Y8
Y88bo. .oooo. .oooooooo .ooooo.
`"Y8888o. `P )88b 888' `88b d88' `88b
`"Y88b .oP"888 888 888 888ooo888
oo .d8P d8( 888 `88bod8P' 888 .o
8""88888P' `Y888""8o `8oooooo. `Y8bod8P'
d" YD
"Y88888P'