On 5/1/13, Samantha Atkins <[email protected]> wrote: > On Wed, May 1, 2013 at 11:57 AM, Mike Archbold <[email protected]> wrote: > >> Regarding #1,.... true if you are trying to sell something in the near >> future. What I learned from programming in the last 25 years or so is >> that there is no point in writing any code unless you fully understand >> the problem at hand. > > > So you totally disagree with Paul Graham, Alan Kay and others that advise > it is sometimes more important to take a more "painterly" approach (as in > oil painting) of trying things and exploration of the problem space using a > set of programming tools? It has not meen my experience in 35 years of > programming (trumped you <g>) that we generally fully understand the > problem at the beginning of creating a software system. We understand > early formulations of goals and have some ideas about approaches and know > from experience and research what sorts of constraints and characteristics > those generally entail. But very seldom would I say there was a full > understanding. > > Once back in early Structured Programming days a manager wanted full SP > techniques applied to a system although we didn't have any CASE tools > (which weren't very good anyway) to help with that. So four of us labored > for about 5 months. We generated an impressive large document full of nice > diagrams, data dictionaries, cross-references.. We felt good about it > because we were quite sure it would be trivial to write the code that did > exactly that after we had thought through all the nooks and crannies in > such detail. But upper management looked at the costs to date and the size > and complexity of such a document and canned the entire thing. :P > > > >> If you start too soon somebody will introduce >> some requirement that seems innocent enough, but throws the design off >> so badly you have to start over. The problem is that people often >> rush to write code to have something to show for it without gaining >> adequate understanding of a problem domain. >> > > Well, that is the thing. You don't really know fully what you want and > your users even more often do not know until you build something and put it > in front of the concerned parties. It is often extremely useful to put a > first guesstimate in people's hands to play with to refine what is actually > desired. Humans are not very good at thinking through all ramifications > and refining what they want to the smallest most powerful statement of > need. They are notoriously bad at whole system thinking. And even worse > at running a computer inside their mind. > > >> >> Now, in the context of AGI, what we are saying is that we want a > > program that does, what? Everything! So that throws a bit of a tire >> iron in the works, creating a seeming deadlock, not easily resolved. >> >> I'm not saying don't write any code. I guess I am saying that I >> wouldn't bank heavily on emergence or some magic happening later to >> make it work. >> > > > Now there I agree with you somewhat. I think without fundamental insights > into General Intelligence that we are very unlikely to get anywhere with > AGI. But there are lots of plausible looking notions about GI out there. > And many of them have not been rendered in software to the satisfaction of > various AGI researchers. Without that rendering it is difficult to sort > out which of these notions are more plausibly useful. > > From another perspective, I don't think we will ever have a full theory of > how General Intelligence works. I think that something more like what > happened via evolution to make us generally intelligent will play a part. > I think we will make systems that have enough of some set of critical > capabilities and enough degrees of freedom around the use and combination > of those capabilities that General Intelligence will emerge. At the least > I think we human hackers are incapable of hacking together more than a > "seed" of a true AGI that needs to go through some > evolution/self-improvement cycle to become truly AGI. > > My 2 cents. > > - samantha > >
Well, mostly what I have done is straight-ahead applications programming. In that realm I don't subscribe to any theory of coding before you have nailed the requirements beyond any doubt. Even a horribly written awful inside program that does what the user wants is much better than an elegant solution to ~part~ of a problem. Which it why I think it's best to spend 90% of the time trying in analysis and the remaining in design and test.... I'm working on a book that has some ideas as to how to approach AGI. (I thought I had it done a few months ago, but discovered some structural issues.... like programming I had to pull it apart at the seams and redo.) When it's done I'll post a link or such here. Mike > > ------------------------------------------- > AGI > Archives: https://www.listbox.com/member/archive/303/=now > RSS Feed: https://www.listbox.com/member/archive/rss/303/11943661-d9279dae > Modify Your Subscription: > https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com > ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
