From: Richard Loosemore (email@example.com)
Date: Thu Sep 08 2005 - 14:37:41 MDT
J. Andrew Rogers wrote:
> On 9/7/05 5:05 PM, "firstname.lastname@example.org" <email@example.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
What!!? I was talking about my thesis. On this list, I have never
introduced any discussion of my thesis system. You told me, in your
original comment, that I never wrote a rigorous specification of the
system i was trying construct in my thesis .... a topic that I had never
introduced, that you could not possibly have known about, and that was
not relevant to the discussion.
> - 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.
Oh, spare me!! I'm sorry, but this is complete BS. If you deal with
massively parallel programming every day, and you think it is no harder
than anything else, then you have never seen it in your life.
Not for a long time have I seen such a ridiculously naive dismissal of
the problems of parallel programming.
> 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
> 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.
> J. Andrew Rogers
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:52 MDT