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 in the "opencog shell" series of emails, where we've argued the merits of python, scheme and clos. I propose setting the bar as follows: Your favorite shell/programming language should allow creating links and nodes so that one line, or fewer, is needed to create a single atom: thus, for example (a twisted NLP example): NounModifier :tv 0.8 Concept bicycle Concept chain A predicate, where ?x is an unknown to be solved for, should be expressible as simply as: NounModifier Concept ?x Concept chain Right now, we have one real-life example that actually works, that actually allows this, this is the guile interpreter, which supports the above; it requires parens to separate the component parts. By contrast, the C++ equivalent takes something like a dozen lines of code, or more, and makes coding with C++ clunky and unsatisfying. If you can come up with a python, or C# equivalent that is equally non-verbose, then its a valid proposal. Another pre-req is that the compiler/interpreter be available under the LGPL or BSD license or equivalent (SIAI rules) The meta-language issue is serious, as I really believe that is where all the action will be/should be. But we are in the very early stages right now. --linas ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=103754539-40ed26 Powered by Listbox: http://www.listbox.com
