Re: Minsky still posting
examachine_at_gmail.com
Date: 03/16/05
- Previous message: Takuon Soho: "Re: When will GOFAI die, for good?"
- In reply to: Matthew Huntbach: "Re: Minsky still posting"
- Next in thread: Matthew Huntbach: "Re: Minsky still posting"
- Reply: Matthew Huntbach: "Re: Minsky still posting"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 16 Mar 2005 00:15:41 -0800
Matthew Huntbach wrote:
> On Mon, 14 Mar 2005 examachine@gmail.com wrote:
>
> > I agree that pattern matching in Prolog is not advanced stuff, but
it's
> > a genuine feature. I use the pattern matching features of haskell
and
> > ocaml extensively when I code in them, while they're based on
types,
> > they seem to me significant features of its own.
>
> Yes, I think pattern matching is more powerful when used with
> the functiomal langauges than used with Prolog.
My point: it doesn't matter which language, I could design it as an
operator in an imperative language.
> > One of the things that makes prolog special is the ability to
define
> > your own recursive grammars, extending the language.
>
> OK, but that's something which has been added to Prolog, it isn't
> part of the logic programming core of Prolog.
No, but it is very logical.
> > Wrt. backtracking, I don't know, I look at it as kind of a
> > library-thing, you could write beautiful backtracking search
functions
> > in a functional language.
>
> If you want to do serious search, you don't want the crude
depth-first
> with backtracking that's built into Prolog.
I agree. That's a major problem, we really want a logical language with
better control on how reasoning is done, hmmm. I liked the approach of
mercury but I couldn't even run the tutorial so I gave up.
[snip]
> > With respect to OOP, I kind of think it's less relevant to
programming
> > than the logical languages. In the primitive C-derivatives,
programmers
> > love OOP because their programming languages do not even have a
proper
> > module system. Yes, it works for GUIs, but a database is not just
> > "another object". A database system, for instance, is used with a
query
> > language. I really don't think a language that cannot interface
with
> > the database linguistically is a high level language. I'd want my
> > language system to know about databases.
>
> If OOP was less relevant to programming than the logical languages,
> the world would be writing programmes in logic languages now rather
> than in object-oriented languages. But it isn't. In 1981, when the
> Fifth Generation project started, it was a believeable claim that
> logic programming would be the way everyone would be going in the
> future. It's important for those of us interested in developing new
> programming langauges to work out why that hasn't been the case - why
> logic langauges (and functional languages) have largely remained the
> preserce of academics.
Ok. But we write programs in poor languages like C/C++ or Java. I don't
regard these languages as good OOP languages even. People use classes
all the time because that seems to be the "right" way, and in their
popular language they don't have modules. So, they are using OO
features in every place that they aren't necessary, e.g. would be more
naturally handled by a generic data type and functions in a module.
Luckily, some well designed modern language systems have proper
modules, functions, type systems, classes.
Functional languages are not popular because they aren't marketed. Poor
language systems like Java are being presented like new stuff and
people buy that crap because it's advertised down our throats.
So my point: OOP is not specific to imperative languages. Remember,
there are classes in modern Prolog. (Object Prolog was the name?) A
class, in prog. lang. theory, is just a set of functions. And
inheritance is basically being able to extend these sets. Subtype
relations are an extra level of programming facility that allows us to
treat one of these guys like the other, this means a lot of code
sharing, and ocaml does this right. So, I agree that "set of functions"
is a useful abstraction, but I'd first want my language to have good
functions first. Good types and modules then. And only then OO.
> When I think of OOP, I think primarily in terms of actors, rather
than
> in terms of OOP as it is used in conventional programming languages
> today. I think the idea of programming as co-ordinating communicating
> actors which are executing concurrently *is* fundamental to
programming.
Yes, but these concurrent agent environment is nowhere near what is
provided by imperative OO languages like C++. All they offer is a
handicapped sequential programmng environment.
Real concurrency is provided by a really concurrent language. And for
that I think it has to be functional, also.
The benefit of OOP lies, in my opinion, in facilitating code reuse,
extensibility, and large-scale software development as well as agent
abstraction which you mention. Without OOP, it might be very difficult
to write something like KDE, where the OO paradigm fits nicely, e.g.
GUI and desktop services. What I don't accept is that it is a
"solution" to majority of computing tasks. An inheritance diagram
doesn't help you much when you are writing a compiler or a data mining
algorithm.
In my work, e.g. academic software devel., you have to prototype
algorithms
and systems fast. I find C++ very unsuitable for that kind of work,
it's
not flexible at all. And for AI, I think it's rather awkward, so yes
I'd
like a language with OO, but preferably a capable language like ocaml
if
possible.
> > An important criterion for a high-level language would be its
> > reflective capability, e.g. how you can reflect on existing code
and
> > manipulate it. This is very good with LISP and Prolog, and it's
awful
> > for most of the modern languages. I call this "reflective
simplicity"
> > and I think it's an important feature.
>
> OK, there's arguments for reflection, but I think it can be overused.
> Self-modifying code should be avoided in most cases. When you see
> novice Prolog programmers using assert/retract, for example, it
almost
> always indicates a failure to get to grips with Prolog rather than an
> appreciation of its more advanced aspects.
On the contrary I would say that an agent without self-modifying code
probably cannot be intelligent. Self-modifying code doesn't mean going
out of bounds and destroying the system. It's nothing more than
launching a complex process quickly. It actually matters a lot for the
universal machine learning algorithms that requires generation and
execution of codes. At any rate, I'm not really referring to Prolog,
although I think they had made us write a Prolog interpreter in Prolog.
So, self-modifying code should be avoided if not needed, but there is
nothing wrong about constructing a code and executing in the stack, or
passing it off to another agent, etc. All those languages used in the
industry are lagging far behind LISP in these elementary aspects of
programming. Programming means, in the sense of Turing, working with
symbols. If you don't even have easy ways to string together symbols
and split them, define simple things like a function that applies a
function to a list, etc., then it is not a very abstract prog. lang.
C++ in most cases doesn't feel much more abstract than assembly with
classes.
Cheers,
-- Eray Ozkural
- Previous message: Takuon Soho: "Re: When will GOFAI die, for good?"
- In reply to: Matthew Huntbach: "Re: Minsky still posting"
- Next in thread: Matthew Huntbach: "Re: Minsky still posting"
- Reply: Matthew Huntbach: "Re: Minsky still posting"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
