Structural optimisation is not compression. Lurk more.


On 28/02/2012, at 3:38 PM, BGB wrote:

> granted, I remain a little skeptical.
> I think there is a bit of a difference though between, say, a log table, and 
> a typical piece of software.
> a log table is, essentially, almost pure redundancy, hence why it can be 
> regenerated on demand.
> a typical application is, instead, a big pile of logic code for a wide range 
> of behaviors and for dealing with a wide range of special cases.
> "executable math" could very well be functionally equivalent to a "highly 
> compressed" program, but note in this case that one needs to count both the 
> size of the "compressed" program, and also the size of the program needed to 
> "decompress" it (so, the size of the system would also need to account for 
> the compiler and runtime).
> although there is a fair amount of redundancy in typical program code (logic 
> that is often repeated,  duplicated effort between programs, ...), 
> eliminating this redundancy would still have a bounded reduction in total 
> size.
> increasing abstraction is likely to, again, be ultimately bounded (and, 
> often, abstraction differs primarily in form, rather than in essence, from 
> that of moving more of the system functionality into library code).
> much like with data compression, the concept commonly known as the "Shannon 
> limit" may well still apply (itself setting an upper limit to how much is 
> expressible within a given volume of code).

fonc mailing list

Reply via email to