Java 8

[Ed Pell]

How does the Opencog team feel about adding code in Java 8?

[Ben Goertzel]

How does a world-class athlete and health-food nut feel about eating
a 100-pound barrel of sugar laced with chocolate, vegemite and
cyanide?


;-)

On Wed, Jul 26, 2017 at 10:53 PM, Ed Pell <edp...@gmail.com> wrote:
> How does the Opencog team feel about adding code in Java 8?
>

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/e6002de8-69ee-4535-baca-6523c3b05865%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Ben Goertzel, PhD
http://goertzel.org

"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin

[Ben Goertzel]

Well but seriously... it depends on how and why...

We are open to anything if it's the best way to achieve some important
functionality...

But we don't want to introduce additional complexities lightly

We have Java in the codebase now, in the form of RelEx ... but we're
planning to eliminate that within the next year...

We are mulling various third-party tools for helping with making
OpenCog massively distributed and scalable, and some of these are
JVM-based (though with C++ APIs)

-- Ben

[Ed Pell]

Yes! I love it when people give definite answers.

So, just to check, the preferred language is Scheme?

[Linas Vepstas]

The prefered language is atomese.  http://wiki.opencog.org/w/Atomese

scheme is there for accidental historical reasons, it just happens to be a really good fit for typed hypergraphs. Java is a terrible fit, it doesn't have this concept.  Javascript feels like it might fit well. Python is awkward -- again, cause both python and java are procedural languages, not functional, and thus have no concept of hierarchy or recursion or any graph-like structure.

The atomspace is defacto implemented in c++ partly for historical reasons, and partly because that provides OK performance.

--linas

On Wed, Jul 26, 2017 at 3:06 PM, Ed Pell <edp...@gmail.com> wrote:

Yes! I love it when people give definite answers.

So, just to check, the preferred language is Scheme?

--

You received this message because you are subscribed to the Google Groups "opencog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/0a580a06-c43a-487c-8a89-3d86b0ce537b%40googlegroups.com.

[Adrian Borucki]

Using JVM stack has an advantage of being able to write code in Scala or Clojure too. I guess Clojure would fit because Scheme is already being used. It does have some differences though, so it wouldn't be a seamless transition.

On Wednesday, 26 July 2017 23:01:08 UTC+2, linas wrote:

The prefered language is atomese.  http://wiki.opencog.org/w/Atomese

The wiki mentions runtime efficiency problems of Atmospace - do you plan to go for that Agda implementation or do you have something else planned?

scheme is there for accidental historical reasons, it just happens to be a really good fit for typed hypergraphs. Java is a terrible fit, it doesn't have this concept.  Javascript feels like it might fit well. Python is awkward -- again, cause both python and java are procedural languages, not functional, and thus have no concept of hierarchy or recursion or any graph-like structure.

The atomspace is defacto implemented in c++ partly for historical reasons, and partly because that provides OK performance.

--linas

On Wed, Jul 26, 2017 at 3:06 PM, Ed Pell <edp...@gmail.com> wrote:

Yes! I love it when people give definite answers.

So, just to check, the preferred language is Scheme?

--
You received this message because you are subscribed to the Google Groups "opencog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.

[Linas Vepstas]

Hi Adrian. I think you missed my point.

The goal is to not write code at all, not in java, not in clojure, not in scala, not in scheme, not in python and not in C++. The goal is to have the machine write it's own code.  The language that the machine writes in is atomese.

Why atomese, and not java, clojure. scala, python, scheme c++? Because atomese has been designed for introspection.  Tht is, it has been intentionally designed to look like the intermediate language used in a compiler, a lot like Gimple in GCC, or the IR in LLVM. The opencog atomese intentionally looks like gimple and IR and intentionally does NOT look like bytecode!

Atomese has also been designed to resemble a relational algebra (aka SQL, or the W3C html query languages). Also, atomese has been designed to be a kind of KR language similar to famous old KR languages, such as prolog or STRIPS.  Its done this way NOT FOR HUMANS, but to allow the machine to introspect and manipulate structures.

Atomese has also been designed to resemble a rule language, such as DROOLS.

Stop thinking of programming languages that humans use. This is NOT ABOUT HUMANS! Its not about the language that is easy for some human programmer to use. If you are a human, scala and clojure are fun, but that is just not what this is about.  We want less human-written code, not more.

--linas

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/9198c298-499c-4523-a97a-4b76a1f34551%40googlegroups.com.

[Ben Goertzel]

I mean -- just making another scripting-language wrapper for Atomspace
and associated cognitive-process interactions doesn't really
accomplish anything, that's all...

Right now we have bindings in Scheme, pretty-thorough ones in python,
very partial ones in Haskell ... but pretty much only the Scheme ones
are used by anyone. I have been debating whether we should just
deprecate the python and Haskell bindings...

We also should introduce nicer ways for application developers to
interface with OpenCog, but that can be via higher-level interfaces,
not necessarily via low-level bindings to each Atomspace and
cognitive-process function...

If some particular useful extension to OpenCog would be most easily
done via Java then, why not.... But just adding more languages for
interfacing w/ OpenCog at a low level doesn't really advance things
IMO.... The hard part of working with OpenCog is not learning Scheme
or C++ ...

-- Ben

> https://groups.google.com/d/msgid/opencog/9198c298-499c-4523-a97a-4b76a1f34551%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Adrian Borucki]

I can see your points, sometimes I forget how ambitious this project is... :)

I suppose you want to make the software do what you want by communicating with it in a natural language and extend its capabilities on its own if it cannot achieve something yet by learning.

[Adrian Borucki]

On Friday, 28 July 2017 09:26:19 UTC+2, Ben Goertzel wrote:

I mean -- just making another scripting-language wrapper for Atomspace
and associated cognitive-process interactions doesn't really
accomplish anything, that's all...

Right now we have bindings in Scheme, pretty-thorough ones in python,
very partial ones in Haskell ... but pretty  much only the Scheme ones
are used by anyone.  I have been debating whether we should just
deprecate the python and Haskell bindings...

Is that Guile kernel for Jupyter being worked on by anybody or is it free for taking?

[AmeBel]

No one is.

Here are example implementations for other scheme dialects

https://github.com/Calysto/calysto_scheme

https://github.com/joeltg/mit-scheme-kernel

Have a blast :-)

[David Xanatos]

Please don’t deprecate the Python bindings.  We’re out here.  We don’t speak up because we’re still light years behind where you folks, the stars of the OpenCog Universe, are and we have nothing of value to contribute…. Yet.  But we’re here, and we have developed a great deal of the structure into which we want to eventually nest OpenCog as the central cognitive organizing structure.  And we’ve developed most all of that in Python J

 

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/537cb934-7058-4db1-8570-b52c2ed77154%40googlegroups.com.

[Linas Vepstas]

On Fri, Jul 28, 2017 at 12:47 PM, Adrian Borucki <gent...@gmail.com> wrote:

I can see your points, sometimes I forget how ambitious this project is... :)

I suppose you want to make the software do what you want by communicating with it in a natural language and extend its capabilities on its own if it cannot achieve something yet by learning.

Well, no one wants to "program in English", but people do give each other instructions in English all the time.  For the robot, I'd like to have a movie-director-screen-actor type interaction, something like  "look left, look right, now smile, smile a bit more, that's right, and now look right at me.  OK, now when I say "go", do that again"

We are certainly at the point where we can hand-craft the above, it's within reach. I got part-way through the above task, by converting the English sentences into an abstract middle form, and then converting this middle form into movements.  This "middle form" is an abstract representation of (self and world) knowledge, encoding "deep" parts of English in such a way that they also fit nicely with spatial knowledge and movement and "facts about he world" in general.

What I built still needs a huge amount of work to be extended and generalized; and since its hand-crafted, so in particular, we need a strategy for that middle-form to be automatically learned.  But I figured that, at first, a hand-crafted middle-form would point the way for what needs to be done.  It is described here: https://github.com/opencog/opencog/blob/master/opencog/eva/architecture/embodiment.pdf

In the meanwhile, there is an effort is to create a scripting language that will allow non-programmer artists to create scripted actions and reactions.  Unfortunately, this completely blows-off and ignores the concept of a "middle form", and so there is no path forward from scripting to a learning system. That's a different problem, though, a harder problem.

--linas

[Ben Goertzel]

> In the meanwhile, there is an effort is to create a scripting language that
> will allow non-programmer artists to create scripted actions and reactions.
> Unfortunately, this completely blows-off and ignores the concept of a
> "middle form", and so there is no path forward from scripting to a learning
> system. That's a different problem, though, a harder problem.

The Ghost authoring language does currently ignore the "middle form",
for reasons of expedience, but is not incompatible with the use of a
middle form... obviously the plan is to go back to that in a couple
months time...

ben

[Matt Chapman]

As a long time Java critic, I find Java 8 vastly more pleasant to use than it's prior versions. I imagine there is a small community of people that would appreciate having Java tools to assist in generating Atomese. 

All the Best,

Matt

--

Standard Disclaimer:
Please interpret brevity as me valuing your time, and not as any negative intention.

--
You received this message because you are subscribed to the Google Groups "opencog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBc3oPGd3xHOJqZYncNUKLL2SB1oUaULHjF--AP1s4AK2g%40mail.gmail.com.