From: J. Andrew Rogers (andrew@ceruleansystems.com)
Date: Thu Sep 08 2005 - 12:37:37 MDT
On 9/7/05 5:05 PM, "rpwl@lightlink.com" <rpwl@lightlink.com> wrote:
> How to you know I *didn't* specify the engineering problem?
I don't, but:
- I've never seen a rigorous specification of the problem from you. Maybe it
is a secret, since rigorous specification is a big chunk of implementing a
solution.
- Even if you did not want to disclose a rigorous specification of the
problem, you have not provided any rigorous specification of this
purportedly necessary software tool.
In short, as far as I can tell the only support for your notion that some
brand new type of software development something or other is required to
solve AI is nothing more than your intuition. Intuition is what got us the
last half century of fabulously successful AI designs, so color me
unimpressed in the absence of evidence of something interesting or new.
> Prior to starting that AI Ph.D. I had worked long and hard on Inmos
> Transputers (do you know what they were? massively parallel hardware with
> a novel parallel programming language integrated in the chip design), so my
> comments about the difficulty level were based on real world experience of
> massively parallel systems.
Parallel == Serial == Parallel. It is not special, just complicated, and
fairly vanilla large systems design knowledge these days. It is complex,
but not *that* complex. I deal with this every day.
The complexity of software development on such systems is extremely
dependent on the nature of the algorithm space one is implementing on them.
The nature of the trade-offs and problems of parallel systems design are
fairly well characterized and known. There are enough dimensions to the
design choices for these things that compilers/languages have a hard time
implementing them automatically across the entire space of program
possibilities. Which is only a problem to the extent that you have to worry
about those design aspects yourself, in the same way that a lack of garbage
collection means you have to worry about memory management. Also a
trade-off; the automagic implementations of such things invariably suck for
some application spaces such that you need to disable them and do it
yourself anyway.
Programming languages have a hard time specifying parallelism behavior
because the scope of behaviors is context sensitive and orthogonal to the
code flow itself. There is no way to elegantly specify all possible graphs
and constraints in a simple ASCII syntax, and so assumptions are buried in
the compiler/interpreter. Which is why every parallel programming language
I am aware of that hides the complexity is broken for some type of
parallelism. This is probably the major reason parallel languages like
Erlang are stuck in niches; unless your software only requires the types of
parallelism supported by the language, the language is basically broken for
parallelism. And many real-world software applications are mixed bags of
parallelism.
But again, this is nothing more than a tool and therefore mostly unimportant
to the larger problem of AI. Every type of parallelism needed can be
implemented in C by a savvy programmer if it is possible at all. A nuisance
sure, but not a major roadblock.
Cheers,
J. Andrew Rogers
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:52 MDT