> That reminds me - one of the great secrets of computing
> appears to be a three-way diff, as exemplified by diff3.
>
> It is packaged in things like CVS/git, so people are
> potentially using it by accident, but I'm not sure what
> the situation is.
>
> I still use CVS and I do the 3-way diffing across an
> entire source base. I only know very simple git so I
> don't use it there.
Linus infamously berated CVS (and SVN) back in 2005 when creating Git.
> But absolutely I need to go back to 1987 or thereabouts
> and get a simple demo of diff3.
>
> I didn't pick it up (by osmosis) until 1995 or so, I think.
>
> However - diff3 and patch can be written in pure C90 -
> that's how I was able to get them working on MVS.
Honestly, I never use it, only normal DJGPP/GNU Diff.
> Regarding the OSes and CPUs - absolutely - if you write
> your tools in a standard language (I know C90 works,
> but I'm not sure what else is available that is portable),
> then you shouldn't need to know or care what OS or CPU
> you are on.
>
> And you only have to go back to 1990 for that. Or 1989
> in fact. It was already there. Perhaps it was more of a
> question of saying "use it - what's wrong with it?"?
Portability isn't easy. You can't please everyone, so some people will always complain or refuse or stand in the way. You kinda have to do everything yourself. (Patches welcome! Fork it and extend it. Too many parallel projects with overlapping goals. But sometimes, rarely, forking is good.)
ANSI Pascal absolutely refused to support conformant arrays. ISO 7185 made it optional (level 1). Use it or do without. You can't win.
CP/M didn't have environment variables (put it in a text file) or subdirs (user workspaces???) or pipes (shell hack needed for temporary files).
DOS had limits on path and filenames and cmdline length in addition to weird memory limits ("usually" limited to 64 kb segments, not counting "huge"), e.g. size_t.
Even though DOS supported getenv(), exit(), fopen() named files at whim, fclose(), fseek(), argc and argv, ISO 7185 Pascal did not.
But POSIX 2008 demands mmap(). Most Linux programs demand UTF-8 (while Windows and Java still use UTF-16, right??). C23 will demand twos-compliment. C99 demanded VLAs and complex numbers while C11 made them optional.
ISO 10206 Extended Pascal and ISO 10514 Modula-2 were not popular. The former had complex numbers, the latter had exceptions. What good is a standard that everyone ignores? (Have you seen modern Fortran? They added A LOT since 1995!) It has been said that it's safer to standardize on existing implementations rather than ideals, but even that is overzealously approved when the typical billion-dollar crowd supports it (but not for long, deprecation always changes its mind).
It's hard for me to explain all of this. Certainly most of you recognize that some things are always missing or hard to implement or unpopular. And yet it's almost always "MORE!!", not less. (Literally, POSIX demands pax and more, but everyone just uses tar and less. GNU Makefiles are considered "portable", not POSIX! Or Bash scripts when the darn thing relies so heavily on fork() that Cygwin has to slowly emulate. Oh, our crappy Bash scripts don't work with DJGPP? Get a better OS! Ugh.)
Ada was supposed to be a better Pascal with tasking, generics, exceptions. C++ is supposed to be a better C with classes, templates, exceptions, etc. Oberon is a better Modula-2 with OOP and garbage collection. A lot has changed since the '90s. It feels like modern software supports less and less hardware since it's so cheap and throwaway. I'm just incredulous that anyone would make a "modern" "standard" that only runs on 2% of existing computers (which will be obsolete in five years or less).
It never ends. To some people nothing is ever good enough. |
Thread view
Board view
