I'm reminded here that JPEG includes arithmetic encoding as part of the standard, but almost everyone uses Huffman because up until a couple years ago arithmetic encoding was patent-encumbered (the patents are expired now). Is anyone aware of a study like Mozilla's that considers JPEG-with-arithmetic-encoding? Or perhaps it does, and I failed to notice?
Most competing file formats seem to beat JPEG by only a slim margin, and what I've read on arithmetic encoding suggests it gives a ~5-10% gain, which would make that difference slimmer still, perhaps vanishing into the uncertainty of the usefulness of these quality benchmarks. Of course, there would be inertia to overcome to support it, as with a new format, but recompiling everyone's libjpeg is surely less work than adding support for whole new file formats. At the very least, it seems there might be a better effort/payoff ratio.
If you're going to break backwards compatibility it would be better to spend the pain on a modern format instead of reviving an arcane and previously unimplemented part of the old JPEG. Like the article admits, we know how to do significantly better now, so a patent free HEVC alternative would be the logical target.
POSIX make really does make auto dependencies hard, but GNU make actually solves this fairly cleanly by adding an include directive. As long as you have a script or program to process a file and spit out its dependencies in make style (e.g., GCC does this for C and C++ with its -M flags), you can just include the outputs of that process and make will do the rest.
For example, here's how I handle a simple C project.
CSRC := [list .c files here]
DEPS := $(CSRC:.c=.d)
[standard statements for building go here]
%.d: %.c
gcc -MM -MF $@ $<
-include $(DEPS)
Poof. Automatic dependency handling. You can see how any sort of dependency that can be detected by some sort of preprocessor can be plugged in here.
Some problems I have encountered with this approach:
1. dash before include. It will cause make to ignore any errors when generating the .d files. It can be pretty difficult to figure out what went wrong. Removing the dash will show a (harmless) error message for every .d file generated, which is pretty annoying.
2. At one time a.c includes b.h and you run make. a.d is created with "a.o: a.c b.h". If at this point you add to b.h an include to c.h, the new dependency of a.o on c.h will never be updated in a.d unless you manually delete it. This can cause some pretty nasty bugs!
This can be solved by adding
-MT $*.o -MT $*.d
to the gcc command line, which causes the dep file to regenerate when one of the dependencies changes (in fact the make manual suggests a similar solution using sed). However this creates another problem: if you remove a header a.h included by a.c (and the #include line to it), a.d still depends on a.h, so make will fail looking for it until you manually delete a.d (and any other dep file depending on the removed header).
tl;dr: this solution leaves much to be desired, and can be dangerous in some conditions.
When I first started programming in C, I did the same thing with pointers (i.e.,
char* str;
instead of
char *str;
).
Unfortunately, this creates the wrong impression that
char* str1, str2;
creates two pointer-to-char variables, whereas actually str1 is a char pointer and str2 is simply a char. Indeed, I was confused on this point myself when I was a newbie, which led to great confusion later on.
The clearest way I've ever found to think about C declarations (ironically, I think I read this in some article maligning C's syntax in favor of Go's), is that each declaration is of the format
[type] [expressions--one for each new variable--that equate to type];
Thus, the way I think of declaring a char pointer is
char [de-referencing the variable (which is a char pointer) to arrive at the char];
char *str;
(Obviously, not everyone is going to agree that that is simple, but it works for me and my brain.)
Anyway, the point is that while typography is great, it can be just as harmful as helpful if you communicate the wrong impression to the reader. And to be fair, it really looks like the author is not at home in C: besides his misconception about pointer declaration, he didn't bat an eye at the old-style argument-declaration syntax that has been obsolete since ANSI C.
Also, I hope I never write a for loop that looks so massively bloated--a matter of opinion I guess.
Less typing is exactly the benefit, and with it less chance of error because of less repeated code. It is also another way of showing parallelism in your code.
And again, the wrong impression is conveyed (that you are declaring a variable of type char* instead of a pointer type that dereferences to a char).
With more complex types, not understanding what is really going on makes code incredibly opaque (and that typographical style ad hoc). What would you do with this:
char *((*func)(char *));
That isn't a char pointer at all. It's a pointer to a function that takes a char pointer as an argument and returns (i.e., evaluates to) a char pointer. It looks incredibly dense (to me, at least), unless I think of it in the way I talked about above (in which case it all makes sense and is kind of cool).
With the convention used in the article, the declaration would be something like this:
char* ((* func)(char*));
Which doesn't make clear why the outside parentheses are needed, or why there is a dereference (or multiplication?) operator in front of the variable name.
The idea of a variable declaration being an expression that evaluates to a basic type is actually the reason why the same symbol * is used in the declaration and in the dereferencing of pointers: they mean the same thing.
Basically, what I am trying to say is that the typographical practice used in the article is at odds with the actual meaning of the statement (and the explanation he gives shows he clearly does misunderstand the statement), which can only lead to confusion in the long run, especially when you encounter code written by other people. Or, as with your example, it can lead to eschewing a useful feature of a language simply because it doesn't look pretty according to your arbitrary whitespace conventions.
Most competing file formats seem to beat JPEG by only a slim margin, and what I've read on arithmetic encoding suggests it gives a ~5-10% gain, which would make that difference slimmer still, perhaps vanishing into the uncertainty of the usefulness of these quality benchmarks. Of course, there would be inertia to overcome to support it, as with a new format, but recompiling everyone's libjpeg is surely less work than adding support for whole new file formats. At the very least, it seems there might be a better effort/payoff ratio.