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. 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 transmission. Chuck 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. >> >> David > > 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 3). > > (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 > mapping). > > > 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 range). > > > but, I could always be wrong here... > > >> On Mon, Feb 27, 2012 at 7:01 AM, Martin Baldan<martino...@gmail.com> wrote: >>> David, >>> >>> 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 ;) >>> >>> -Martin >>> >>> >>> On Mon, Feb 27, 2012 at 3:54 AM, David Girle<davidgi...@gmail.com> wrote: >>>> Take a look at the page: >>>> >>>> http://piumarta.com/software/maru/ >>>> >>>> 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. >>>> >>>> David >>> >>> >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
