On 2/27/2012 4:23 PM, Charles Perkins wrote:
Hello everyone.

I think of the code size reduction like this:

A book of logarithm tables may be hundreds of pages in length and yet the 
equation producing the numbers can fit on one line.

VPRI is exploring "runnable math" and is seeking key equations from which the 
functionality of those 1MLOC, 10MLOC, 14MLOC can be automatically produced.

It's not about code compression, its about functionality expansion.

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).

looking it up, I found some statistics here:

Debian 5.0 was 324 Mloc.

Windows NT 4 was 12 Mloc.
Windows XP was 45 Mloc.

now, can a person write something like Windows XP, in, say 1/45 the size, and throw on top of this a reasonably complete application suite (browser, office apps, games, compilers for various languages, ...)?

now, can a person write an analogue of Windows XP in 1/2250 the amount of code?...

I have my doubts.

I also like to think of programming systems as bicycles, with levels of 
abstraction in the system as gears -- and shifting gears in todays programming 
systems is clunky. It would be nice to have a continuously variable 

you can make things less clunky, yes, but this is not necessarily the same as "I can unleash full on programming magic".

it is roughly along the lines of claiming that a new transmission will allow one to outperform a car and travel at full highway speeds, on said bicycle. nevermind if said car actually burns through more total energy in 1 minute than a person does in 1 day.

"damn, this transmission is smooth, it is easy riding traveling 75mph on the freeway while pulling a trailer... on my bicycle...".


On Feb 27, 2012, at 2:20 PM, BGB wrote:

On 2/27/2012 1:27 PM, David Girle wrote:
I am interested in the embedded uses of Maru, so I cannot comment on
"how to get from here to a Frank-like GUI".  I have no idea how many
others on this list are interested in the Internet of Things (IoT),
but I expect parts of Frank will be useful in that space.  Maybe 5kLOC
will bring up a connected, smart sensor system, rather than the 20kLOC
target VPRI have in mind for a programming system.

IoT: had to look it up, but it sounds like something which could easily turn 
very cyber-punky or end up being abused in some sort of dystopic future 
scenario. accidentally touch some random object and suddenly the person has a 
price on their head and police jumping in through their window armed with 
automatic weapons or something...

and escape is difficult as doors will automatically lock on their approach, and random 
objects will fly into their path as they try to make a run for it, ... (because reality 
itself has something akin to the "Radiant AI" system from Oblivion or Fallout 

(well, ok, not that I expect something like this would necessarily happen... or 
that the idea is necessarily a bad idea...).

granted, as for kloc:
code has to go somewhere, I don't think 5 kloc is going to work.

looking at the Maru stuff from earlier, I would have to check, but I suspect it 
may already go over that budget (by quickly looking at a few files and adding 
up the line counts).

admittedly, I don't as much believe in the tiny kloc goal, since as-is, getting 
a complete modern computing system down into a few Mloc would already be a bit 
of an achievement (vs, say, a 14 Mloc kernel running a 4 Mloc web browser, on a 
probably 10 Mloc GUI framework, all being compiled by a 5 Mloc C compiler, add 
another 1 Mloc if one wants a 3D engine, ...).

yes, one can make systems much smaller, but typically at a cost in terms of 
functionality, like one has a small OS kernel that only run on a single 
hardware configuration, a compiler that only supports a single target, a web 
browser which only supports very minimal functionality, ...

absent a clearly different strategy (what the VPRI people seem to be pursuing), 
the above outcome would not be desirable, and it is generally much more 
desirable to have a feature-rich system, even if potentially the LOC counts are 
far beyond the ability of any given person to understand (and if the total LOC 
for the system, is likely, *huge*...).

very course estimates:
a Linux installation DVD is 3.5 GB;
assume for a moment that nearly all of this is (likely) compressed 
program-binary code, and assuming that code tends to compress to approx 1/4 its 
original size with Deflate;
so, probably 14GB of binary code;
my approx 1Mloc app compiles to about 16.5 MB of DLLs;
assuming everything else holds (and the basic assumptions are correct), this 
would work out to ~ 849 Mloc.

(a more realistic estimate would need to find how much is program code vs data 
files, and maybe find a better estimate of the binary-size to source-LOC 

granted, there is probably a lot of redundancy which could likely be eliminated, and if 
one assumes it is a layered tower strategy (a large number of rings, with each layer 
"factoring out" most of what resides above it), then likely a significant 
reduction would be possible.

the problem is, one is still likely to have an initially fairly large "wind up time", so 
ultimately the resulting system, is still likely to be "pretty damn large" (assuming it 
can do everything a modern OS does, and more, it is still likely to be probably well into the Mloc 

but, I could always be wrong here...

On Mon, Feb 27, 2012 at 7:01 AM, Martin Baldan<martino...@gmail.com>   wrote:

Thanks for the link. Indeed, now I see how to run  "eval" with ".l" example
files. There are also ".k"  files, which I don't know how they differ from
those, except that ".k" files are called with "./eval filename.k" while ".l"
files are called with "./eval repl.l filename.l" where "filename" is the
name of the file. Both kinds seem to be made of Maru code.

I still don't know how to go from here to a Frank-like GUI. I'm reading
other replies which seem to point that way. All tips are welcome ;)


On Mon, Feb 27, 2012 at 3:54 AM, David Girle<davidgi...@gmail.com>   wrote:
Take a look at the page:


it has the original version you have + current.
There is a short readme in the current version with some examples that
will get you going.


fonc mailing list

fonc mailing list
fonc mailing list
fonc mailing list

fonc mailing list

Reply via email to