David Clark wrote:
My AGI and my language was never designed to have "millions and billions of
asynchronous, concurrent units". My design certainly has the ability for
run a few thousand events simultaneously and pass messages efficiently
between them but this is not what you are asking. My language would be
totally inadequate for the kind of solution you envision but I would argue
that for the kinds of systems I envision, current languages are equally
ill-suited. I have a summary of the features in my system and some examples
concerning why Lisp wasn't suitable at www.rccconsulting.com/aihal.htm
Here are a few thoughts on the list at your site.
The following is the list of language requirements I thought an AI would
minimally need.
1. Object Oriented.
OO is great except when it isn't. What features do you want from OO?
Encapsulation? Modularity? Inheritance? Reuse? All wonderful but OO is
not the only and in some situation not the best way to achieve them.
Single dispatch or multi-dispatch? Class based or prototype based or a
mix? Frame type contstructs? Inheritance or delegation?
2. All Classes, Methods, Properties, Objects can be created and changed
easily by the program itself.
Is there a MOP? Can the implementation details be tweaked freely? Can
cross cutting concerns be cleaned expressed?
3. Efficiently run many programs at the same time.
What is and isn't a "program" or unit of computation in your thinking?
Is this part of the language or the OS or do you agree with Alan Kay
that an OS is where you put all that stuff you failed to account for it
the language?
4. Fully extensible.
So there is a MOP and the constructs of the language can be change,
added to, implemente differently fairly freely?\
5. Built-in IDE (Interactive Development Environment) that allows
programs to be running concurrently with program edit, compile and run.
IDE is just another program or set of programs. I don't see it as being
particular built-in except languages can support interpretation,
reflection, JIT compilation, run time code generation and loading of
code and so on that make development and deployment much more
efficient. Lisp machines had exactly the type of IDE you are talking
about. Smalltalk still does. Both Lisp and Smalltalk allow changing
code on the fly without restart.
6. As simple as possible.
Hard to get much simpler than Lisp with as much power.
7. Quick programming turnaround time.
As above concerning interactive iterative devolopment without
edit-compile-link-test cycles. If you are concerned with portability
writing the language in Java or even smalltalk would give you guaranteed
portability on about every system out there. You could also write in
Python or Ruby and be much more productive that in C/C++ although you
would want to later optimize crucial sections.
8,Fast where most of the processing is done.
In the language or in things written in the language or both? Lisp has
been interpreted and compiled simultaneously and nearly seamlessly for
20 years and has efficiency approaching compiled C in many problem
domains.
Only some programs spend most of their time in indexing, searching and
other things you write about optimizing internally.
Lisp allows the creation of new "primitives", optimized as highly as you
can imagine at any time.
If this is mainly about developer productivity and power then getting
too caught up in efficiency before addressing productivity and
expressiveness and maintainability would be a mistake.
9. Simple hierarchy of Classes and of Objects.
1. Simple Class inheritance.
2. Simple external file architecture.
3. Finest possible edit and compile without any linking of object
modules.
4. Scalable to relatively large size.
5. Built in SQL, indexes, tables, lists, stacks and queues.
6. Efficient vector handling of all data types.
7. Internet interface.
8. Runs on Windows PC machines.
9. Can run as multiple separate systems on the same computer or in
the background
Class inheritance is only one of many useful mechanisms. Single or
multiple? Mixins supported? Typing ? What do you have in mind as
needed external file arhicecture? What kind of module structure? SQL?
Why? Don't you want more OQL at least? What kind of tables? Data
structures are trivial to build up in any reasonably powerful language
so I guess some of this is about what is in the standard library.
On threading I have build an deployed systems running hundreds of
threads as appservers on fairly normal mid to high-end desktops under
both Windows and Linux coded in Java. So it is certainly false that
noone does this. Many locking problems can be ameliorated by using more
of a work-queue based approach. Often mechanism like thread-local
storage can further reduce the amount of locking needed. Threads can be
done in a much more lightweight manner than some of the standard
implementations. See Erlang for ones set of interesting approaches.
Why not drop external files altogether? How about keeping source and or
bytecode in a database to facilitate creating/searching/loading code as
the IDE/programs are created and run? OO and especially persistent OO
has implied to me the possibility and desirability of getting away from
"files" for about three decades now. Some Lisp and Smalltalk
environments used "images" to hold a snapshot of an entire code/working
enrionment/system. Others, like the IBM Java and Smalltalk systems
stored everything in a database. I have done some work with "cloud of
objects" environments where there are no applications per se. Instead
their are persistent and distributed objects, classe, code, data and and
environment for finding objects and sending messages and loading objects
as necessary in ore more processes on one or more machines on the fly on
an as needed basis. A set of objects and code used in a word processor
may also be used in many other contexts once some of the "file" and
"application" barriers are removed.
12. edit and compile?
Why need an explcit compiler at all? You don't (or don't see it unless
you choose to) in some language environments. Why not create an
instance of a class under development, code up or modify a method and
immediately with no compilation at all send it the message to see how it
works and immediately use the reflective capabilities of the language to
inspect the object? Why not have an environment where something like
lisp "trace" function is available so you immediate test shows you
exactly what is called with what data in what order without needing to
fire up a debugger?
Lisp has been used for some of the largest programs in existence. You
are confused about the "list" in lisp. Lisp includes every type of data
structure you can imagine.
What is in your database? What kind of database? OODB, relational,
hybrid? Highly transparent? What kind of transactionas support?
Pessimistic or optimistic locking or both? What granularity of locking?
What kind of caching? Recoverability? Redundancy? Change logs? Most
dbms systems today have means to extend them to some degree in multiple
programming languages. Most have means to be used by multiple
programming languages although there is considerable "impedance
mismatch" unless quite a bit is done to get beyond it like some of the
OODB systems for OO languages and as highly transparent persistence
mechanisms as possible given the constraints of the DB machinery and the
language at hand (a specialty of mine) . There are also many embedded
databases that have some strength in some problem domains. For a system
with many processes and perhaps distributed across multiple machines a
separate database process or processes is generally required.
Runs on Windows Machines
I think you are pretty much stark raving here. :-) Linux is not
cryptic compared to Windoze in the least. I have worked with Window
many, many times. When I have a Windows machine that I bought myself it
inevitably gets converted to Linux within 6 months. Usually this is
after I have had to reinstall the OS at least once to fix the breakage
that is the Windows registry. It IDEs for C/C++ are not bad if you
don't mind having window-isms leak into every part of your code. .Net
is a step into much better direction but I can get most of that goodness
under Mono and run on more platforms. Windows GUI is not very good at
all once you have lived on the Mac world for very long. The Mac running
OS X gives most of the advantages of Unix on a very visually
well-designed system with excellent tools. Windows is a disaster for
hacking. Most of the nomal cli tools are utterly brain dead. I always
load cygwin and live under it as much as possible on windoze. We want
even get into the virus breeding idiocy that is Windows.
At the least go the Mac route. That is my choice today for the most of
the things I care about. Especially now that I can easily run Linux
and/or Windows when I need to in virtual machines (Parallels). For
many years I did not have any Windows machine and I had no trouble
working just fine with the rest of the world. What few Windows programs
I needed ran fine under Wine or had quite useable alternatives.
If your language is one OS dependent then it sucks from the beginning.
You say you looked at different languages such as Lisp but your comments
say you didn't really understand what you were looking at at all.
- samantha
-----
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
