Mark -
I don't know you, and have no bones to pick with you. I have no bases, nor do I have motivations for doing so.
Picking a language is not a science - so to "prove" or "test" things, well ...
If you believe I'm wasting your time - don't bother reading - or replying to my posts.
I, as much as you (or anyone else on this thread / list) have the right to say what we like. And by consequence, your email to me below - as inapropriate, and frankly childish, as it was - was well within your right.
My only comment is ... Stop taking things like attacks. Get some thick skin. Because in science, you need it. And believe it or not, I am saying that out of respect to you. Maybe you're having a bad day - we all do - but if anyone wastes time, it is people shouting at others.
Look at your email to me again. Was this called for? Look at your subsequent email to Eliezer. Come on man. Lighten up a little.
Everyone else ... I apologize for taking your time to read this email. I'm just hoping it'll make anyone from flaming people and calling them stupid.
Enough said. I think we can all get along, and learn something from each other.
~Aki On 18-Feb-07, at 1:21 PM, Mark Waser wrote:
[Aki] This is by far too strong a statement - and most likely incorrect.Don't play with "most likely"s. Either disprove my statement or don't waste our time.Mark, do you work at Microsoft?No, but the question is irrelevant (as is your working at Microsoft -- except so far as your believing that does prove something proves that your beliefs are questionable).there are more reasons than time I have to elaborate why I can't agree with your statement.So give us ONE! Why are you wasting my attention if you won't back up your statements with verifiable facts?And, from a practical programmatic way of having code generate code, those are the only two ways. The way you mentioned - a text file - you still have to call the compiler (which you can do through the above namespaces), but then you still have to bring the dll into the same appdomain and process. In short, it is a huge performance hit, and in no way would seem to be a smooth transition.Spoken by a man who has clearly never tried it. I have functioning code that does *exactly* what I outlined. There is no perceptible delay when the program writes, compiles, links, starts a new thread, and executes the second piece of new code (the first piece generates a minor delay which I attribute to loading the compiler and other tools into memory).Also, even if it *did* generate a delay, this function should happen often enough that it is a problem and there are numerous ways around the delay (multi-tasking, etc).BTW - My apologies to Chuck for misattributing the quote. ----- Original Message ----- From: "Aki Iskandar" <[EMAIL PROTECTED]> To: <agi@v2.listbox.com> Sent: Sunday, February 18, 2007 12:36 PMSubject: **SPAM** Re: Languages for AGI [WAS Re: [agi] Priors and indefinite probabilities]Before I comment on Mark's response, I think that the best comment on this email thread came from Pei, who wrote ...<quote> "I guess you can see, from the replies so far, that what language people choose is strongly influenced by their conception of AI. Since people have very different opinions on what an AI is and what is the best way to build it, it is natural that they selected differentlanguages, based mainly on its convenience for their concrete goal, oreven tried to invite new ones. Therefore, I don't think there is a consensus on what the most suitable language is for AI." <end quote>However, there was an upshot to all the replies to the original question - which as with any emotionally charged discourse, there are nuggets of learnings (I'm gaining insights into languages - thus others have also learned things as well).ok - now to breifly reply[Mark] Far and away, the best answer to the best language question is the .NET framework.[Aki] This is by far too strong a statement - and most likely incorrect. Mark, do you work at Microsoft? I have, for 3 years (not that it makes me a .NET expert by any means), and there are more reasons than time I have to elaborate why I can't agree with your statement. Two of the nicest things about .NET are ADO.NET and Reflection. Java (which I think is not as strong or as pleasurable to work with) has reflection. But something that is readily available for Java (and soon .NET - but not yet) object database management systems (ODBMS) - which may be of better use than traditional RDBMS - and if not, still much better than ADO.NET - from a developers viewpoint when programming against a datastore.Chuck is also absolutely incorrect that the only way to generate code by code is to use Reflection.Emit. It is very easy to have your code write code in any language to a file (either real or virtual), compile it, and then load the resulting library (real or virtual) anytime you want/need it. There is absolutely no run- time cost to this method (if you're keeping the compiled code somewhere in your knowledge base) since you're dealing with compiled codeI'm the one that made that comment about Reflection.Emit - but I also included CodeDOM. And, from a practical programmatic way of having code generate code, those are the only two ways. The way you mentioned - a text file - you still have to call the compiler (which you can do through the above namespaces), but then you still have to bring the dll into the same appdomain and process. In short, it is a huge performance hit, and in no way would seem to be a smooth transition. THere would be lots and lots of "hang time" or waiting - and if you did this often, its just completely impractical. Any execution speed advantages that .NET, in its compiled form, as opposed to a comparatively slower runtime - such as Python for example, is lost. Way lost.However, I completely agree with Mark's comment as to use existing technologies such as RDBMSs - and to not reinvent the wheel. I know nothing about Novamente, and so this comment is not meant as "Novamente should have ...". Its a general comment to not reinvent wheels. If the wheel doesn't fit perfectly, you can build an "adapter" for it.Bottom line ... Pei is correct. There will not be a consensus on what the mostsuitable language is for AI. Regards, ~Aki On 18-Feb-07, at 11:39 AM, Mark Waser wrote:What is the best language for AI begs the question --> For which aspect of AI? And also --> What are the requirements of *this particular part* of your AI and who is programming it.Far and away, the best answer to the best language question is the .NET framework. If you're using the framework, you can use any language that has been implemented on the framework (which includes everything from C# to the OCAML-like F# and nearly every language in between -- those obviously many implementations are better than others) AND you can easily intermix languages (so the answer to best language will vary from piece to piece).(as long as you know how to manage spawning and killing threads and processes so that you don't keep nine million libraries loaded that you'll never use again).I also wouldn't sneer at using an established enterprise-class database to serve as one or more of your core knowledge stores. There is *a lot* of infrastructure where many ongoing AI projects have re-invented the wheel over and over again as they have to add features that come free with such a product. I have to wonder how much further along Novamente would be if it had used something like Oracle or SQL Server instead of building their own custom knowledge store and having to constantly upgrade it (and yes, I am quite convinced that you could implement all of the necessary functionality in either with less programming time and with faster execution than your current Novamente version).The dumbest thing AGI researchers do is re-invent the wheel constantly when isn't necessary. I'm heartily with Richard Loosemoore and his call for building a research infrastructure instead of all the walled gardens (with long, low learning curves and horrible enhancement curves) that we have currently.I also have to dispute Samantha's "I question whether you can get anywhere near the same level of reflection and true data <-> code equivalence in any other standard language." Reflection is a core functionality of the .NET framework and available to *all* .NET languages in a much more computationally convenient form than how most of LISP's reflection turns out. I would also argue that a higher level retrospection framework is more necessary and more easily built in .NET than in LISP (given that you're dealing with a whole framework rather than just a language). And, of course, all of this ignore the ultimate trump that several flavors of LISP are available on the .NET framework.----- Original Message ----- From: "Chuck Esterbrook" <[EMAIL PROTECTED]>To: <agi@v2.listbox.com> Sent: Saturday, February 17, 2007 5:49 PMSubject: **SPAM** Re: Languages for AGI [WAS Re: [agi] Priors and indefinite probabilities]On 2/17/07, Aki Iskandar <[EMAIL PROTECTED]> wrote:Richard, Danny, Pei, Chuck, Eugen, Peter ... thanks all for answeringmy question....C# is definitely a productive language, mainly due to the IDE, and itis faster than Java - however, it is strongly typed.Perhaps the disadvantage to C#, form my perspective, is that the onlyways to generate code (by code) is by using Reflection.Emit, andCodeDOM namespaces. However, the performance hit is faaaar to costlyto run it - because it has to be compiled (to MSIL / bytecode) andthen the class type has to be loaded, and only then interperated / run.Java suffers the same fate, and is slower than C#.Python is a duck typed language, and has very rich flexibility when designing datastructures. In addition, it has a few ways to evaluatecode on the fly (enabling code that writes code).I've cranked out mounds of Python and C#, so I have a few things tooffer on the subject. Regarding C#'s productivity coming mostly from the IDE, I think that is only part of the picture. C# offers many highlevel, productive features including garbage collection, classes,exception handling, bounds checking, delegates, etc. while at the same time offering excellent runtime speed. Those features aren't available in C and some of them aren't even available in C++. C# is also better designed and easier to use than Java primarily because it was designedafter Java as a better version of Java.Python is still faster to crank out code with (and Ruby as well), butboth Python and Ruby are ridiculously slow. That will be a serious problem if your application is CPU intensive and I believe any AGI will be (though early exploratory programs may not). One approach is to use two languages: Yahoo cranked out theirweb-based mail site with Python so they could develop it quickly. Then after it stabilized, they reimplemented it in C++ for performance. Of course, it would be nice if one language could truly cover both. Butmore on that at the end of this message. :-) Regarding the overhead of generating code in C#: * Your AI app may or may not require code generation. * Python runs so relatively slow that if you execute the generatedcode repeatedly, the C# version of the app will still outperform it.Btw I use WingIDE for Python and recommend it. (And of course VS 2005 for C#.)Having said all that--I get frustrated by these situations:(1) I crank out my solution in Python in record time and then grow oldwatching it execute. (2) I watch my C# code fly at runtime, but it takes me 2-3 times longer to write it. Bleck!So I'm working on a language that combines features from the two. Ittargets the .NET platform so that it can leverage the work alreadydone on garbage collection, machine code, etc. as well as the numerous third party tools and libraries. (Likewise for Novell Mono--the opensource clone of .NET.) Cobra is currently at a "late alpha" stage. There are some docs(including a comparison to Python) and examples. (And pardon my plainlooking web site, but I have no graphics skills.) Here it is: http://cobralang.com/It runs as fast as C# and codes almost as quick as Python. It also haslanguage level features for quality control, including contracts,compile-time null checking and unit tests. These are found in neitherPython nor C# (but are found in some other languages).Hey, we're on one of my favorite topics! Feel free to ask questions ormake comments. :-) -Chuck ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303
----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303
