10 ms·
Good question! As you say SHRDLU was the best program of that time. I've read Winnograd's book and looked at the SHRDLU source code (not that I'm much of a li
by joe_the_user 6y ago
Good question!
As you say SHRDLU was the best program of that time.
I've read Winnograd's book and looked at the SHRDLU source code (not that I'm much of a lisp hacker but I got some time). It's built-on a parser and planner (logic program, pre-prolog). And it's built the old-fashioned-way, rewriting the source code with the parser rewriting input and then re-rerunning and other harry things. I think this achieves the parsing of idiomatic constructions on a high level. I believe the "raw lisp" of the day was both incredibly powerful since you could do anything and incredibly hard to scale ... you could do anything.
Winnograd wrote it himself but I think that's because he had to write it himself. In a sense, a programmer is always most productive when they are writing something by themselves because they don't have to explain anything they are doing (until the fix-ups and complexity overwhelm them but the base fact remains). And in the case of SHRDLU, Winnograd would have had an especially hard time explaining what he was doing. I mean, there was a theory behind - I've read Winnograd's book. But there was lots and lots of brilliant spaghetti/glue-code to actually make it work, code that jumped module and function boundaries. And the final had a reputation of being very buggy, sometimes it worked and sometimes it didn't. And Winnograd was a brilliant programmer and widely read in linguistics and other fields.
The software industry is an industry. No company wants to depend on the brilliance of it's workers. A company needs to produce based on some sort of average and a person working with just average skills isn't going to do SHRDLU.
So, yeah, I think that's why actual commercial programs never reached the level of SHRDLU
- _emacsomancer_ 6y agoSo what you're saying is that we really shouldn't be relying on industry for good AI?
- joe_the_user 6y agoWell, an "industrial model" is a model of a factory and it seems unlikely you could product a fully-functional, from scratch GFAI program like SHRDLU in something like a factory. Perhaps one could create a different kind of enterprise for this but it's kind of an open problem.
- YeGoblynQueenne 6y agoWinograd made changes to the Lisp assembly to make SHRDLU work and he never back-ported them to his SHRDLU code, but his original version worked fine and was stable. The experience of breaking refers to later versions that were expanded by his doctoral students and others and to ports to java and I think C. The original code was written in 1969 but inevitably suffered from bit rot in the intervening years so it's true that there is no stable version today that can reliably do what Winograd's original code could do... but Winograd's original code was rock solid, according to the people who saw it working. There's some information about all that here: http://maf.directory/misc/shrdlu.html http://maf.directory/misc/shrdlu.html [Dave McDonald] (davidmcdonald@alum.mit.edu) was Terry Winograd's first research student at MIT. Dave reports rewriting "a lot" of SHRDLU ("a combination of clean up and a couple of new ideas") along with Andee Rubin, Stu Card, and Jeff Hill. Some of Dave's interesting recollections are: "In the rush to get [SHRDLU] ready for his thesis defense [Terry] made some direct patches to the Lisp assembly code and never back propagated them to his Lisp source... We kept around the very program image that Terry constructed and used it whenever we could. As an image, [SHRDLU] couldn't keep up with the periodic changes to the ITS, and gradually more and more bit rot set in. One of the last times we used it we only got it to display a couple of lines. In the early days... that original image ran like a top and never broke. Our rewrite was equally so... The version we assembled circa 1972/1973 was utterly robust... Certainly a couple of dozen [copies of SHRDLU were distributed]. Somewhere in my basement is a file with all the request letters... I've got hard copy of all of the original that was Lisp source and of all our rewrites... SHRDLU was a special program. Even today its parser would be competitive as an architecture. For a recursive descent algorithm it had some clever means of jumping to anticipated alternative analyses rather than doing a standard backup. It defined the whole notion of procedural semantics (though Bill Woods tends to get the credit), and its grammar was the first instance of Systemic Functional Linguistics applied to language understanding and quite well done." Dave believes the hardest part of getting a complete SHRDLU to run again will be to fix the code in MicroPlanner since "the original MicroPlanner could not be maintained because it had hardwired some direct pointers into the state of ITS (as actual numbers!) and these 'magic numbers' were impossible to recreate circa 1977 when we approached Gerry Sussman about rewriting MicroPlanner in Conniver." Regarding the advantage of a lone programmer- that's real, but large teams have built successful software projects before, very often. I guess you don't even need a big team, just a dozen people who all know what they're doing. That shouldn't be hard to put together given FANG-level resources. Hell, that shouldn't be hard to do given a pool of doctoral students from a top university... but nowadays even AI PhD students would have no idea how to recreate something like SHRDLU. Edit: I got interested in SHRDLU recently (hence the comments in this thread) and I had a look at Winograd's thesis to see if there was any chance to recreate it. The article above includes a link to a bunch of flocharts of SHRDLU'S CFG but even deciphering those hand-drawn and occasionally vague plans would take a month or two of doing nothing else, something for which I absolutely do not have the time. And that's only the grammar - the rest of the program woudl have to be reverse-engineered from Winograd's thesis, examples of output from the original code or later clones, etc. That's a project for a team of digital archeologists, not software developers.