I challenge anyone making such claims to construct an even _moderately_ realistic example of where such reduction would be possible.
Here is a very simple and already very optimistic model that is still way below a 100x reduction: say my program consists nearly exclusively of sorting of various arrays and I write out bubble sort in full each time using for loops etc. rather than call a sort() procedure. Bubble sort takes roughly 20 lines of code to implement, so I would at best get a reduction of close to a 20x, rather than a 100x one.
It that is true, it should be possible to get large wins in LOC if one either is willing to give up orders of magnitude in speed and memory usage, or is equipped with a sufficiently advanced compiler.
There likely also is some room for improvement if one is willing to change the file format (.psd is not known for its consistency), but that would likely be a rounding error.
The reduction comes from making the code way more abstract and much more difficult to reason about in concrete contexts. So ya, it is probably possible, but no, our heads might not be very capable in writing/maintaining/debugging such code even if the computer could execute it. As an extreme, consider "very small code" contests in the demo scene, where various crazy tricks (self modifying code) are used to drastically reduce code sizes, none of which would ever be used in practice and have little SE value.
That being said, a 100x reduction in code size seems like an exaggeration.
I looked that up and got this sample of that book: http://www.cs.cornell.edu/courses/CS5860/2011fa/documents/Gr...
Looking up Stepanov's book, landed on his slide deck about the book.
Interestingly enough, both are about the remainder algorithm, and Gries' mentions a "large program" of "3000 lines", which reminded me of the other comment and the 3000000 to 30000 figure.
[Stepanov's deck: http://stepanovpapers.com/EoP-StanfordEE380.pdf]
http://blg89.net/blog/wp-content/uploads/2013/11/The-Science...
https://smile.amazon.com/Mathematics-Generic-Programming-Ale...
Just looked at the ToC of this book and there is an entire chapter on Groups in that book ! Not only Groups but also goes into Rings as well...
Must read this book.
[0] https://en.wikipedia.org/wiki/Monoid
[1] "Brian Beckman: Don't fear the Monad" https://www.youtube.com/watch?v=ZhuHCtR3xq8
https://smile.amazon.com/Elements-Programming-Alexander-Step...
The main selling point of this approach is that it can cut out a lot of code
In this talk, Sean Parent, at that time working on Adobe Photoshop, estimated that the PS codebase could be reduced from 3,000,000 LOC to 30,000 LOC (=100x!!) if they followed ideas from the book https://www.youtube.com/watch?v=4moyKUHApq4&t=10s
Another point of his is that the explosion of written code we are seeing isn't sustainable and that so much of this code is algorithms or data structures with overlapping functionalities. As the codebases grow, and these functionalities diverge even further, pulling the reigns in on the chaos becomes gradually impossible.
Bjarne Stroustrup (aka the C++ OG) gave this book five stars on Amazon (in what is his one and only Amazon product review lol).
https://smile.amazon.com/review/R1MG7U1LR7FK6/