Matter compiler

From Biohack

Hey Eric,

I have not been neglecting your last email. Some other things going on in life that are taking away from my time to think and play. Specifically, my computer setup is far from redundant and had a power adapter electrical problem earlier this month, so I have been restricted to other computer terminals in the house that aren't exactly mine and so on. And on top of this, it's the month for CollegeBoard AP exams (second-year calculus, literature, newtonian physics, economics (hah!), psych, all that fun stuff). So reviewing without a computer has been an interesting experience. Wisdom teeth are poking through, throbbing pain; weird month to have, because it's also exhilerating to see all of my otherwise divergent projects coming together much more thoroughly.

For (some) updates:

http://heybryan.org/mediawiki/index.php/2008-05-07

-- but really I'm scattered all over the place, even when I don't have my own computer to myself; it's a rather odd experience, but also exhilerating, like I said.

So I wanted to get back to the matter compiler subject. I'll do a more thorough reply to your last email to me soon enough, probably when I get the laptop setup fixed (a week at most). I was trying to think of a way to word the exact problem that the matter compiler idea presents. As I thought, the more I realized that it's not all that much of a problem really. The best analogy that I have been able to come up with is the open source microprocessor groups out there on the internet (opencores.org, IIRC -- can't check my bookmarks at the moment). When they have a new architecture, which can be coded for in very abstract terms of VHDL or Verilog, they have somewhat of a problem if they are using a novel instruction set architecture in terms of pins, ALUs, etc. And then think about gcc and the other compiler projects. Mostly gcc. That's on the other side of the problem space. They have a compiler, and they can target for speciifc platforms. You have the compiler bootstrapping problem too. Anyway, it should be theoretically possible to present a file representing your ISA to a program from gcc and have it then make a compiler for that architecture, yes? The same with the fab lab scenario. The ISA is simply much more than flipping bits and bytes; it's also controlling specific instruments within the physical environment, compiling either hardcode for the firmware of the instruments or compiling realtime interpreted code to send off to them (i.e., they could be dumb actuators (analogy to dumb terminals)). I also see an analogy with this and the multicore architectures, or Google's MapReduce (or is it Hadoop?), where you split a linear program into many parallel chunks and have integration via MPI (a message passing protocol). The idea of splitting up linear programs into parallel programs for different nodes on the network. But ultimately isn't the problem that you have some sort of tool, you have your drivers and your specifications and so on, and you need to plug this in to the 'matter compiler' that you locally have, yes? And so how is it going to know the full extent of the functionality, much less the wide range of possibilities of combining these functional pieces together to ultimately execute the 'dance' that will put together whatever 'thing'/project you are compiling? At best you can have programs to automatically detect functionality on your local network. Plug and play. Common interfaces. "Hey, this arm is like arm 3910, performing tests ..." etc. But at the same time I can't help but think that if you're going to allow nonstandardized components (which you most absolutely *should*), you're going to have to somehow bridge a few gaps, like (1) semantic compiled machine code for manufacturing versus the human readable instructions for what to do (meaning the 'dance' steps must be *discretized* so that natural language can be dumped out to the reader, and (2) those discretized dance steps have to be programmed and/or learned to some extent, as providing functionality themselves, so that the software system can select from them and either do a genetic algorithm to find a good dance routine, or something else. I don't know. You can probably see where the problems are coming from.

As I was thinking earlier tonight, one of the ideas that hit me was that we might just have to admit that standardization is going to be needed, as much as we wish it were not so. The reason is truly simple: you're either Edison or you're not. Edison had to permutate through tens of thousands of possible little gadgets before he got to the package that he really, really wanted. And if you're not Edison, you're importing the tools and instruments others have already made. Simple as that. Yes, you can make your own instruments, but where does that creativity come from? Until we have a truly descritized case of 'creativity that defies the laws of contextualism' (etc.), we'll have to settle with a matter compiler that has to be *programmed* to make the general classes of packages and so on. In truth, this 'insight' isn't really anything new .. it's simply that you can't represent the functionality of something in semantics. Otherwise you wouldn't search Google with words ... you'd search Google with the full program already, and what good is that if you already know?

I may be ranting here. Have you given any thoughts to the problems of designing such a matter compiler?

- Bryan