Wednesday, February 21, 2018

Kurzweil the "father of AI" You've Got to be Kidding me!

A recent article

calls out Ray Kurzweil as the father of AI. What HOGWASH.

First, I own a K2000RS and had a K1200. I know mr. Ray quite well. He is if anything the father of the speaking reading machine for the blind and sample instrument synthesis. NOT AI.

Let's talk the real history.

The Dartmouth Conference of 1956 was organized by Marvin Minsky, John McCarthy and two senior scientists: Claude Shannon and Nathan Rochester of IBM. ... At the conference Newell and Simon debuted the "Logic Theorist" and McCarthy persuaded the attendees to accept "Artificial Intelligence" as the name of the field

Image result
Marvin Minsky

Minsky is often the one I think of first when someone asks about founders of AI, and Turing pops to mind second simply because he did so much. 

Don't forget Kunihiko Fukishima's Cognitron who was so far ahead of his time its frightening, and a giant whose shoulders I stand on. 

Image result for kunihiko fukushima
Dr. Fukushima

 or Edelman's Neural Darwinism. Giants both. They forged a lot of principles of Noonean Inc. 

Image result for gerald edelman
Dr. Gerald Edelman M.D.

What about Karl Pribram? Holographic Brain theory? 

Image result for karl pribram
Karl Pribram

What about the first commercial AI - Expert Systems. Nope Ray wasn't there either

developed by Edward Feigenbaum and his students. Dendral, begun in 1965, identified compounds from spectrometer readings. MYCIN, developed in 1972, diagnosed infectious blood diseases. They demonstrated the feasibility of the approach

Image result for edward feigenbaum
Dr. Edward A. Feigenbaum

What about early neural networks? John Hopfield gave us those. His background was in molecular biology. Ray was mysteriously absent. 

Image result for john hopfield
John Hopfield

What about the founder of semantic nets - Ross Quillian? And what about companies? IBM and Bolt Beranack and Newman (sp?) which was whispered quietly as I was a senior at Vassar as how brilliant they were and how hard their interviews were. I ended up starting with IBM Research. But I wished I were smart enough for BBN. 

Image result for Ross Quillian
Ross Quillian

We ended up using Ross's work for enhancing search engines in 1996 and doing things miles ahead of the dummies at Google, but success isn't always about being the smartest. 

It seems the one big thing Kurzie did was write a rather poor book full of 30 year old research on AI, and then hire out of date hacks like Geoffry Hinton at Google. Lawd help us all.  Alright, Hinton is ok as a general theorist but he is hardly a pioneer and his Ted talk showed what I was studying in 1988!!!

Daniel Dennet led much of the work in symbolic representation in Cognitive science

Image result for daniel dennett
Daniel Dennett
Dennett is our great american cognitive philosopher and still alive and going strong. May you live another 100 years Daniel we are in debt!!!

David Rumelhart was a brilliant psychologist and thinker into the development of mind. Sadly he is no longer with us. 

Image result for david rumelhart
David Rumelhart

Roger Schrank a UT Austin alumn is still going strong as the CEO of Socratic Arts, a learning company. 

Image result
Roger Schrank

We also have Terry Winograd from Stanford's HCI group. He pioneered much of the work in natural language processing

Image result for terry winograd
Dr. Terry Winograd

Obviously an incomplete list. But I encourage to read and research these early pioneers and true fathers of AI. And hopefully as I am getting old and gray I will make the grade as well someday. These true fathers and founders, and 

As a aside, I am noted as the originator of the concept of the Neural Cube, a massive 3 dimensional self organizing structure of billions of neurons, as well as being a principal engineer in the early days of genetic programming. But I get few articles and I can't write my book without giving away too many secrets so.. that is on hold for now. But I will guarantee it will be light years past dim brain Kurzweils feeble mind. Is that harsh? Ray I love your chip wiring and early electronics, but a AI pioneer you were not. 

Book in Denmark...

I always marvel at how far and wide my books are sold... I really need to work with a translation house to get them available in native languages...

Tuesday, February 20, 2018

The Perils of Dependency Injection

When we worked with the Java Spring Framework (4.3 at the time) one of the things we had to adjust to was the fact that rather than have a J2E app server spring provided access to our realized objects through their dependency injection framework.

Now this is a lot like Windows versus linux. One time windows insisted on installing a security patch even though I had done everything I could possibly do to turn that off. So my computer rebooted twice, took several hours at load time with a threat "dont turn off!" and finally died altogether.

The idea of the computer taking control from you and believing "I know best" is really a new thing. One of the few pleasures we used to have was that computers unlike wives only did what we told them to do.

Now Spring is a lot like that. One of the first things that was confounding was what classes which used other classes which used other classes could actually be injected. This often wasn't as obvious as possible or predictable. Several times simple atomic classes which used other injects were not allowed. Why? This made no sense. It had to do with the internal class representation they had hacked into their injection representational model classes. It didn't have to make sense.

Another big issue which I think I mentioned before is how in the case of errors, again Spring would intercept the exception and re-wrote it to the callers callers callers class. The first time I tried to fix it with simple encapsulation. No dice it was thrown above that. Then we put in another set of classes specifically to get the throw. Nope still no dice. Finally we had a fully artifical layer calling a fascade calling into the classes. This made the code very hard to read and maintain. Why were we doing this? One developer suggested removing all this unnecessary code. Another did something similar the day of the big demo.

Now why WHY is this dependency injection stuff so high on the hog? I can always predict the classes I need from a constructor factory and have the same abilities. I've never had issues with getting hit with a new class type it just never comes up. Well a lot of it has to do with the MOCKIT or MOKITO type of testing. Testing can be difficult with the requirement to be in a fully live system. By using Mock object injection you can spoof your system to make it think its live and still test the function with the right state, say for example an object that has a handle which must be set by the system.

Again, yes useful, but real system tests always prove better. And rarely have I seen mockit object testing done well or ubiquitously it simply takes too long to setup.

Dependency injection seems like something they realized they could do, without actually looking at the pattern of use. does it have its place on some projects? Perhaps. But I advise caution.