3 ms·
I think the article's original point (and mine as well) was that considering the size of the code (i.e. the DNA) as a measure of the complexity of the task is t
by akeefer 16y ago
I think the article's original point (and mine as well) was that considering the size of the code (i.e. the DNA) as a measure of the complexity of the task is totally disingenuous when you don't have (to use your analogy) the web server, the libraries you're calling, the parser/compiler/linker for the language, the operating system for the server along with its drivers/TCP stack/etc., the processor it runs on, the mother board, or the storage. In order to turn 10,000 lines of code into a web application, you need millions of lines of code (and Verilog or whathaveyou) in terms of infrastructure.
The problem for AI is not just encoding the DNA, as it were, it's in building all those other pieces around it. Estimating the complexity of building a software brain based on the amount of information in DNA is like estimating the complexity of building a web application using 1950's hardware. "It's only 10,000 lines of code! How hard can that be? All we have to do is write the code, plus the frameworks, programming language, and operating system, plus do all the hardware design."
- rayval 16y agoGood point. Not only that, but a case can be made that one cannot build such as system as an end stage. Instead, it appears that ontogeny must recapitulate phylogeny. The system must develop over time as a result of inputs (and the remembered collection of past inputs encoded in the DNA). It would be as if in order to build Twitter with Ruby on Rails, you first had to program a tax calculation application in Cobol on a 1950s mainframe.
- ewjordan 16y agoIt's only 10,000 lines of code! How hard can that be? All we have to do is write the code, plus the frameworks, programming language, and operating system, plus do all the hardware design. Except that DNA doesn't even come close to being a high level language, since the low level details were not specifically designed for compressibility of the code (in fact, the low level details, the "bare metal ops", are pretty much fixed by the for-all-intents-and-purposes random laws of physics, which means we shouldn't assume that they enable any particularly high compressibility ratios for anything). So a more apt comparison would be if we saw an assembly language program in some strange incomprehensible assembly language and said "It's only 10,000 lines of operations on the bare metal! Now all we have to do is figure out how the hell the system this runs on works, and how we can translate that code into a more sensible (and probably vastly more compact) form." ...which might even be a harder problem, to be fair. Kurzweil's essentially proposed evidence of existence of an algorithm of length N that does whatever it is we mean by intelligence. Which is fine, and I think is probably correct (IMO, even his estimate about the minimal amount of code it would take is probably too high, though that's another story). But he's overlooking the fact that the mere existence of such a compact algorithm doesn't help us find it at all, and I think a lot of the complaints others have made about his statements are more aimed at that leap of logic, not the existence claim itself. I completely agree that even brain scanning tech might not help us simulate the important bits very well, even if we did have access to that tech and computers fast enough to run the sims.