Re : [agi] Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
http://www.swig.org/ http://gbbopen.org/ in my project to encapsuled texai,opencog,yarp,oscar,openNARS,i think utilise swing and gbbopen and therefore common-lisp i agree linas good day bruno - Message d'origine De : Linas Vepstas <[EMAIL PROTECTED]> À : agi@v2.listbox.com Envoyé le : Vendredi, 30 Mai 2008, 20h12mn 53s Objet : [agi] Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p Hi, > About C++ versus C# ... > > Linas Vepstas is a very experienced software developer who can likely > argue the practical advantages of C++ in the Linux environment, more > adeptly than I can. He is involved with OpenCog, as well. Heh. I see my name used in vain. I have a long response: -- merits of C++ -- merits of other languages -- the opencog shell language/meta-langauge The last point is the most interesting, but its at the end. First: C++ is far from a perfect language, and many people hate it. Let me give an example of one common reason why C coders hate C++ (and Java): -- The idea that most data and algorithms "naturally" group themselves into collections or "objects" is fundamentally correct. Most C programs these days are written in an object-oriented or object-directed style. However, C++ (and Java even more so) force the programmer into making a premature design decision about the grouping of data and subroutines into objects. In C++, you feel foolish if you write a function that isn't a method on some class. In java, you can't. In most/all OO languages, you are forced, very early in the design cycle, to segregate *everything* into objects. For most data and subroutines, this is not a problem. However, for some things, there's a gray area: its simply not clear how an algorithm should be split into objects, and how some routines should be assigned to which objects. In C, when you get the assignment of a subroutine to an object wrong (and everyone, of all skill levels, gets it wrong), there is little or no penalty to fixing it later (or even letting it slide...). For C++, and Java, and other OO languages, the penalty is high, even very high. You have to refactor a *lot* of code. As a result, bad design decisions made early on tend to get frozen into the code: its too much work to refactor. As time goes on, this quick-setting concrete becomes even stiffer. As compared to C code, most C++ and Java code tends to be "uglier" by various subjective standards that coders like to apply. Things are in the wrong places, things are too hard to use, it takes too many lines of code to accomplish simple, small things. The coder attitude tends to be, "yeah, right, we should fix that someday, but in the meanwhile, lets just live with it because I'm busy right now." Of course, "someday" never comes. One of the worst I ever saw was code from Apple, for drawing lines. Normally, a line draw is a tight loop of multiply-adds, splatting out pixel colors at very high rates. The Apple code turned each pixel into an object. The inner loop ran an object constructor, an object destructor and several method calls. No wonder the code was 100 times slower than "real" code! = Anyway, that's all beside the point. OpenCog is in C++, I see no strong reason to re-write. Yes, garbage collection sure would be nice: it is *really really* fun to not have to deal with garbage collection. Coding in a language with closures would be nicer. etc. etc. I don't think any of this is enough, at this point in time, to convert opencog to another language. Let me give reasons below. But first: Seems like C# would be a bad choice, for one very important reason: someday, maybe soon, I beleive that the "interesting" opencog problems will outstrip the cpu and ram requirements of plain desktop machines. This rules out windows as a viable runtime environment. The vast majority of big-iron machines simply don't run windows. Of the top 500 supercomputers in the world, exactly six of them run windows: http://www.top500.org/stats/list/30/osfam Something approaching 95% of them run unix, 85% of them run Linux. The results aren't as badly skewed on smaller machines, but if you start polling hardware with more than 8GB RAM and more than 8 cpu's, you will find that most of them run linux or solaris or AIX. Simply stated, Windows just doesn't play in what Sun marketing likes to call "red-shift computing". But AGI, by its very nature, does. == But: I saved the most important point for last: I am hoping that, before too long, most opencog users will not be writing C++ code that accesses the low-level interfaces directly. I am hoping instead that they will be gluing this algorithm to that data structure, where the data structures are not shorts and ints and floats of C++, but are rather Atoms, Nodes and Links, TruthValues,
[agi] Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
Hi, > About C++ versus C# ... > > Linas Vepstas is a very experienced software developer who can likely > argue the practical advantages of C++ in the Linux environment, more > adeptly than I can. He is involved with OpenCog, as well. Heh. I see my name used in vain. I have a long response: -- merits of C++ -- merits of other languages -- the opencog shell language/meta-langauge The last point is the most interesting, but its at the end. First: C++ is far from a perfect language, and many people hate it. Let me give an example of one common reason why C coders hate C++ (and Java): -- The idea that most data and algorithms "naturally" group themselves into collections or "objects" is fundamentally correct. Most C programs these days are written in an object-oriented or object-directed style. However, C++ (and Java even more so) force the programmer into making a premature design decision about the grouping of data and subroutines into objects. In C++, you feel foolish if you write a function that isn't a method on some class. In java, you can't. In most/all OO languages, you are forced, very early in the design cycle, to segregate *everything* into objects. For most data and subroutines, this is not a problem. However, for some things, there's a gray area: its simply not clear how an algorithm should be split into objects, and how some routines should be assigned to which objects. In C, when you get the assignment of a subroutine to an object wrong (and everyone, of all skill levels, gets it wrong), there is little or no penalty to fixing it later (or even letting it slide...). For C++, and Java, and other OO languages, the penalty is high, even very high. You have to refactor a *lot* of code. As a result, bad design decisions made early on tend to get frozen into the code: its too much work to refactor. As time goes on, this quick-setting concrete becomes even stiffer. As compared to C code, most C++ and Java code tends to be "uglier" by various subjective standards that coders like to apply. Things are in the wrong places, things are too hard to use, it takes too many lines of code to accomplish simple, small things. The coder attitude tends to be, "yeah, right, we should fix that someday, but in the meanwhile, lets just live with it because I'm busy right now." Of course, "someday" never comes. One of the worst I ever saw was code from Apple, for drawing lines. Normally, a line draw is a tight loop of multiply-adds, splatting out pixel colors at very high rates. The Apple code turned each pixel into an object. The inner loop ran an object constructor, an object destructor and several method calls. No wonder the code was 100 times slower than "real" code! = Anyway, that's all beside the point. OpenCog is in C++, I see no strong reason to re-write. Yes, garbage collection sure would be nice: it is *really really* fun to not have to deal with garbage collection. Coding in a language with closures would be nicer. etc. etc. I don't think any of this is enough, at this point in time, to convert opencog to another language. Let me give reasons below. But first: Seems like C# would be a bad choice, for one very important reason: someday, maybe soon, I beleive that the "interesting" opencog problems will outstrip the cpu and ram requirements of plain desktop machines. This rules out windows as a viable runtime environment. The vast majority of big-iron machines simply don't run windows. Of the top 500 supercomputers in the world, exactly six of them run windows: http://www.top500.org/stats/list/30/osfam Something approaching 95% of them run unix, 85% of them run Linux. The results aren't as badly skewed on smaller machines, but if you start polling hardware with more than 8GB RAM and more than 8 cpu's, you will find that most of them run linux or solaris or AIX. Simply stated, Windows just doesn't play in what Sun marketing likes to call "red-shift computing". But AGI, by its very nature, does. == But: I saved the most important point for last: I am hoping that, before too long, most opencog users will not be writing C++ code that accesses the low-level interfaces directly. I am hoping instead that they will be gluing this algorithm to that data structure, where the data structures are not shorts and ints and floats of C++, but are rather Atoms, Nodes and Links, TruthValues, Predicates, Schemas, & etc. By working at this higher conceptual level, I'm hoping that the C++ issue will fade away: No one runs around saying "Microsoft should rewrite thier OS kernel in .net" or "the Linux kernel should be rewritten in java". That would be silly. I hope the opencog-in-C++ debate will soon become equally silly. Ahh, but the stuff on top of opencog: what language should that be in? This is where the debate should happen. The original plan was for that language to be "Combo", but that has drifted a bit sideways. Some of this debate has occurred
[agi] Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
Mark,
If it were possible to make both C# and C+ versions of the core
(AtomTable and scheduler), and have both C# and C++ MindAgents run on
both, then we would have a favorable situation in terms of allowing
everyone to use their own fave languages and development environments.
-- Ben G
On Mon, May 26, 2008 at 7:18 AM, Mark Waser <[EMAIL PROTECTED]> wrote:
> While all the language wars continue, I'd like to re-emphasize my original
> point (directly copied from the original e-mail) -- One of the things that
> I've been tempted to argue for a while is an entirely alternate underlying
> software architecture for OpenCog -- people can then develop in the
> architecture that is most convenient and then we could have people
> cross-port between the two.
>
> Seriously people, I'm not asking anyone to move away from what *you* are
> familiar with if you don't want to. I'm saying that maybe we should
> deliberately attempt to open this up so that we get *more* contributions and
> viewpoints -- at the admitted cost of needing better documentation and
> control -- which is really necessary anyways. My "belief" is that seeing
> what happens will cause a migration -- but I'm not invested in that belief
> and would be happy and see huge benefits either way.
>
> Mark
>
> P.S. Thank you for the forward Ben.
>
> - Original Message -
> From: Ben Goertzel
> To: [EMAIL PROTECTED]
> Sent: Sunday, May 25, 2008 8:29 PM
> Subject: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
>
> This email thread on the AGI list really seems more appropriate for the
> OpenCog list... so I'm forwarding it here...
>
> -- Ben G
>
>
> --
> From: Mark Waser <[EMAIL PROTECTED]>
> Date: Sun, May 25, 2008 at 4:23 PM
> To: agi@v2.listbox.com
>
>
> Yeah, I'll certainly grant you that. The unfortunate problem is that people
> coming in late don't see the prior arguments and then engage in behavior
> that they believe is similar but entirely without the scientific rigor that
> you normally follow but don't always visibly display.
>
> Also, on the other hand, for certain classes of issues where you are less of
> an expert -- like in large-scale systems architecture (both software and
> conceptual), a number of your previously posted arguments are *I believe* at
> best questionable if not outright wrong. The fact that these assumptions
> aren't open for inspection at a convenient location is problematical if many
> other things are built on top of them and then they turn out to be wrong.
>
> We need to start to gather the best of these assumptions and debates in one
> place (probably a wiki) because long-term e-mail looping is not efficient.
> I've had this as a low priority thought for the AGI-Network but I think that
> I'm going to escalate it's priority substantially and see if I can't come up
> with a conceptual design for such a wiki (with scaled and isolated
> privileges) over the next couple of weeks.
>
> One of the things that I've been tempted to argue for a while is an entirely
> alternate underlying software architecture for OpenCog -- people can then
> develop in the architecture that is most convenient and then we could have
> people cross-port between the two. I strongly contend that the current
> architecture does not take advantage of a large part of the newest advances
> and infrastructures of the past half-decade. I think that if people saw
> what could be done with far less time and code utilizing already existing
> functionality and better tools that C++ would be a dead issue.
> --
> From: Ben Goertzel <[EMAIL PROTECTED]>
> Date: Sun, May 25, 2008 at 4:26 PM
> To: agi@v2.listbox.com
>
>
> Somehow I doubt that this list will be the place where the endless
> OS/language
> wars plaguing the IT community are finally solved ;-p
>
> Certainly there are plenty of folks with equal software engineering
> experience
> to you, advocating the Linux/C++ route (taken in the current OpenCog
> version)
> rather than the .Net/C# route that I believe you advocate...
>
> -- Ben G
> --
> From: Lukasz Stafiniak <[EMAIL PROTECTED]>
> Date: Sun, May 25, 2008 at 5:24 PM
> To: agi@v2.listbox.com
>
>
> No, I believe he advocates OCaml vs. F# ;-)
> (sorry for leaving-out Haskell and others)
> --
> From: Mark Waser <[EMAIL PROTECTED]>
> Date: Sun, May 25, 2008 at 5:59 PM
> To: agi@v2.listbox.com
>
>
> Cool. An *argument from authority* without even having an authority. Show
> me those "plenty of folks" and their reasons for advocating Linux/C++.
> Times have changed. Other alternatives have advanced tremendously. You are
> out of date and using and touting obsolete software and development
> methods. I *don't* believe that you can find an expert who has remained
> current on technology who will back your point.
>
> {NOTE: It's also always interesting to see someone say that the argument is
> OS/language vs. framework/language (don't you know enough to compare apples
> to apples?)]
>
> Mor
[agi] Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
One of my major points that we've lost in all this is that *every* piece should have clean, well-specified interfaces and APIs such that the language of one piece really shouldn't have an effect on the language of another. C++ runs just fine under .Net (albeit as "unmanaged code"). If I were to create a .Net fork, I would still have both C# and C++ versions and let developers use both and choose between them as necessary. The best way to start a .Net fork would be to just get the current C++ to compile and run under .Net. Then I'd start trying to help with the documentation . . . . then the C#. - Original Message - From: "Ben Goertzel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: Sent: Monday, May 26, 2008 10:10 AM Subject: Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p Mark, If it were possible to make both C# and C+ versions of the core (AtomTable and scheduler), and have both C# and C++ MindAgents run on both, then we would have a favorable situation in terms of allowing everyone to use their own fave languages and development environments. -- Ben G On Mon, May 26, 2008 at 7:18 AM, Mark Waser <[EMAIL PROTECTED]> wrote: While all the language wars continue, I'd like to re-emphasize my original point (directly copied from the original e-mail) -- One of the things that I've been tempted to argue for a while is an entirely alternate underlying software architecture for OpenCog -- people can then develop in the architecture that is most convenient and then we could have people cross-port between the two. Seriously people, I'm not asking anyone to move away from what *you* are familiar with if you don't want to. I'm saying that maybe we should deliberately attempt to open this up so that we get *more* contributions and viewpoints -- at the admitted cost of needing better documentation and control -- which is really necessary anyways. My "belief" is that seeing what happens will cause a migration -- but I'm not invested in that belief and would be happy and see huge benefits either way. Mark P.S. Thank you for the forward Ben. - Original Message - From: Ben Goertzel To: [EMAIL PROTECTED] Sent: Sunday, May 25, 2008 8:29 PM Subject: Mark Waser arguing that OpenCog should be recoded in .Net ;-p This email thread on the AGI list really seems more appropriate for the OpenCog list... so I'm forwarding it here... -- Ben G -- From: Mark Waser <[EMAIL PROTECTED]> Date: Sun, May 25, 2008 at 4:23 PM To: agi@v2.listbox.com Yeah, I'll certainly grant you that. The unfortunate problem is that people coming in late don't see the prior arguments and then engage in behavior that they believe is similar but entirely without the scientific rigor that you normally follow but don't always visibly display. Also, on the other hand, for certain classes of issues where you are less of an expert -- like in large-scale systems architecture (both software and conceptual), a number of your previously posted arguments are *I believe* at best questionable if not outright wrong. The fact that these assumptions aren't open for inspection at a convenient location is problematical if many other things are built on top of them and then they turn out to be wrong. We need to start to gather the best of these assumptions and debates in one place (probably a wiki) because long-term e-mail looping is not efficient. I've had this as a low priority thought for the AGI-Network but I think that I'm going to escalate it's priority substantially and see if I can't come up with a conceptual design for such a wiki (with scaled and isolated privileges) over the next couple of weeks. One of the things that I've been tempted to argue for a while is an entirely alternate underlying software architecture for OpenCog -- people can then develop in the architecture that is most convenient and then we could have people cross-port between the two. I strongly contend that the current architecture does not take advantage of a large part of the newest advances and infrastructures of the past half-decade. I think that if people saw what could be done with far less time and code utilizing already existing functionality and better tools that C++ would be a dead issue. -- From: Ben Goertzel <[EMAIL PROTECTED]> Date: Sun, May 25, 2008 at 4:26 PM To: agi@v2.listbox.com Somehow I doubt that this list will be the place where the endless OS/language wars plaguing the IT community are finally solved ;-p Certainly there are plenty of folks with equal software engineering experience to you, advocating the Linux/C++ route (taken in the current OpenCog version) rather than the .Net/C# route that I believe you advocate... -- Ben G -- From: Lukasz Stafiniak <[EMAIL PROTECTED]> Date: Sun, May 25, 2008 at 5:24 PM To: agi@v2.listbox.com No, I believe he advocates OCaml vs. F# ;-) (sorry for leaving-out Haskell and others) -- From: Mark Wa
[agi] Re: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
While all the language wars continue, I'd like to re-emphasize my original
point (directly copied from the original e-mail) -- One of the things that I've
been tempted to argue for a while is an entirely alternate underlying software
architecture for OpenCog -- people can then develop in the architecture that is
most convenient and then we could have people cross-port between the two.
Seriously people, I'm not asking anyone to move away from what *you* are
familiar with if you don't want to. I'm saying that maybe we should
deliberately attempt to open this up so that we get *more* contributions and
viewpoints -- at the admitted cost of needing better documentation and control
-- which is really necessary anyways. My "belief" is that seeing what happens
will cause a migration -- but I'm not invested in that belief and would be
happy and see huge benefits either way.
Mark
P.S. Thank you for the forward Ben.
- Original Message -
From: Ben Goertzel
To: [EMAIL PROTECTED]
Sent: Sunday, May 25, 2008 8:29 PM
Subject: Mark Waser arguing that OpenCog should be recoded in .Net ;-p
This email thread on the AGI list really seems more appropriate for the
OpenCog list... so I'm forwarding it here...
-- Ben G
--
From: Mark Waser <[EMAIL PROTECTED]>
Date: Sun, May 25, 2008 at 4:23 PM
To: agi@v2.listbox.com
Yeah, I'll certainly grant you that. The unfortunate problem is that people
coming in late don't see the prior arguments and then engage in behavior that
they believe is similar but entirely without the scientific rigor that you
normally follow but don't always visibly display.
Also, on the other hand, for certain classes of issues where you are less of
an expert -- like in large-scale systems architecture (both software and
conceptual), a number of your previously posted arguments are *I believe* at
best questionable if not outright wrong. The fact that these assumptions
aren't open for inspection at a convenient location is problematical if many
other things are built on top of them and then they turn out to be wrong.
We need to start to gather the best of these assumptions and debates in one
place (probably a wiki) because long-term e-mail looping is not efficient. I've
had this as a low priority thought for the AGI-Network but I think that I'm
going to escalate it's priority substantially and see if I can't come up with a
conceptual design for such a wiki (with scaled and isolated privileges) over
the next couple of weeks.
One of the things that I've been tempted to argue for a while is an entirely
alternate underlying software architecture for OpenCog -- people can then
develop in the architecture that is most convenient and then we could have
people cross-port between the two. I strongly contend that the current
architecture does not take advantage of a large part of the newest advances and
infrastructures of the past half-decade. I think that if people saw what could
be done with far less time and code utilizing already existing functionality
and better tools that C++ would be a dead issue.
--
From: Ben Goertzel <[EMAIL PROTECTED]>
Date: Sun, May 25, 2008 at 4:26 PM
To: agi@v2.listbox.com
Somehow I doubt that this list will be the place where the endless OS/language
wars plaguing the IT community are finally solved ;-p
Certainly there are plenty of folks with equal software engineering experience
to you, advocating the Linux/C++ route (taken in the current OpenCog version)
rather than the .Net/C# route that I believe you advocate...
-- Ben G
--
From: Lukasz Stafiniak <[EMAIL PROTECTED]>
Date: Sun, May 25, 2008 at 5:24 PM
To: agi@v2.listbox.com
No, I believe he advocates OCaml vs. F# ;-)
(sorry for leaving-out Haskell and others)
--
From: Mark Waser <[EMAIL PROTECTED]>
Date: Sun, May 25, 2008 at 5:59 PM
To: agi@v2.listbox.com
Cool. An *argument from authority* without even having an authority. Show
me those "plenty of folks" and their reasons for advocating Linux/C++. Times
have changed. Other alternatives have advanced tremendously. You are out of
date and using and touting obsolete software and development methods. I
*don't* believe that you can find an expert who has remained current on
technology who will back your point.
{NOTE: It's also always interesting to see someone say that the argument is
OS/language vs. framework/language (don't you know enough to compare apples to
apples?)]
More importantly, I don't believe that I've ever explicitly endorsed C#.
What I've always pushed is the .NET framework because 1) it's got far more
already built infrastructure than anything else and 2) you can mix and match
languages so that you can use the most appropriate language in any given place
and still use another language where it is more appropriate.
So, I'll take up your challenge . . . .
I've develope
