Hacker News Reader

estimated that the PS codebase could be reduced from 3,000,000 LOC to 30,000 LOC (=100x!!)

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.

I don't doubt that your conclusion is correct, but what if the sort is used in 10 other functions, each of which is used 10 times? If you inlined everything you would end up with 100 copies of bubble sort. The code blowup is exponential in the level of nesting.

Indeed. Another venue for why it cuts out code is that it makes code more reusable. As a result, you are more likely to integrate nicely with already written libraries than write your own code. Technically, this is a way of reducing your codebase as well lol.

I doubt the 100x range, too, but Photoshop is decades old and, likely, has lots of its filters written in assembly for speed, with zillions of variants for all kinds of sometimes long gone CPUs and GPUs. It also still may have its own memory manager.

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.

Reducing a single bubble sort in code size doesn't do much, because it is used many times and its code size cost is well amortized. However, if you had many bubble sorts coded in your program with special cases, then consolidating those into one very abstract/parametric version could be a big win.

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.

I'd expect more opportunities for reduction in code size to arise when you use fancy algorithms (not sorting) on generic algebraic structures that have many models in your program. For example, when I was a student, I implemented a library of numerical methods for my own use in class. It benefited a lot from being implemented as generically as possible.

That being said, a 100x reduction in code size seems like an exaggeration.

The book 'The science of programming' of David Gries is also a nice introduction to writing programs using mathematical logic and reasoning. The book is inspired by the techniques of Dijkstra and Hoare, and written in a way that's easy to follow.

I guess this is a whimsical aside/

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]

Jeez, was about to buy it but it's about 90. What's the deal with this pricing?

I did a google search of the book and found a pdf as the first result:

http://blg89.net/blog/wp-content/uploads/2013/11/The-Science...

I have not yet read "Elements of Programming," but there is another book "From Mathematics to Generic Programming," also co-authored by Alexander Stepanov, which links Abstract Algebra to program design. I found the latter very approachable:

https://smile.amazon.com/Mathematics-Generic-Programming-Ale...

I always had a strong belief that principles of Group Theory must correlate into writing type systems.

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.

In a Group, every element has an inverse element. If you drop this property, you get a Monoid.[0] Functions under function composition form a Monoid (or Monoidal Category). Brian Beckman did a nice intro video to this at MS Channel 9 a few years back.[1]

[0] https://en.wikipedia.org/wiki/Monoid

[1] "Brian Beckman: Don't fear the Monad" https://www.youtube.com/watch?v=ZhuHCtR3xq8

Groupoids, a generalization of groups, factor heavily into type theory!

I think what you want is Category Theory.

Question -- clearly, when you look at Haskell, you see abstract algebra. Were Stepanov's ideas big influencers of Haskell, or vice versa, or neither?

Stepanov and Musser were working on generic programming in the 80s[0][1], which predates Haskell. I suspect parametric polymorphism was common in the FP world by that time, but I don't know whether it was used as an organising principle to the extent that Stepanov promotes.

[0] https://en.wikipedia.org/wiki/Alexander_Stepanov

[1] https://en.wikipedia.org/wiki/David_Musser

Note: apparently both Sean Parent and Bjarne Stroustrup contributed to the book, so their evaluation may not be entirely unbiased.

Still sounds interesting.

Sorry for a fluff comment, but +1 for using Amazon Smile links.