From: Carl Feynman (carlf@shore.net)
Date: Sat Apr 28 2001 - 22:41:20 MDT
Ben Goertzel wrote:
>
> ...
> The second is the creation of an efficient & scalable programming language
> with a purely formal semantics. C# may fulfill this criterion; Peter Voss
> is evaluating it for this purpose. Java is formal but not yet efficient and
> scalable enough; an improved JVM could solve the problem, particularly a JVM
> specialized for large-scale AI. C is efficient and scalable but its use of
> pointers means that its formal semantics needs to include a formal model of
> heap memory, which makes the task of inference-driven self-modification
> MUCH more difficult for a C program. [When I say C I include C++]
Actually, a subset of a language that met this criterion would suffice. For
example, you could define a subset of C++ that had roughly the semantic power of
Java or Eiffel or some other formalizable language. By writing the system in
that subset, you get to use the good compilers available for C++, but keep the
programs possible to reason about. One problem is that you may want to use
substantial bodies of existing code (libraries and the like) that won't fit in
the subset.
I suspect that Python is a particularly good substrate for this trick of
defining a tractable subset. It's already got fairly clean semantics, and its
metaobject protocol introduces additional semantic flexibility that can be used
to warp parts of the language that don't fit into your favorite model.
In fact, subsetting is a reasonable strategy even for non-self-rewriting
programs: if you insist on using C++, it is wise to confine yourself to a
carefully chosen subset, to ease human comprehension of the programs. I know
shops that follow rules like these:
--No multiple inheritance.
--No pointers, only references.
--No references, only pointers.
--All objects must support reference-counted garbage collection.
--Don't use char* for strings, use some better locally developed class.
--No RTTI.
--No <dynamic_cast>.
The problem is that C++ is such a huge and unwieldy language that simply to
maintain sanity, you have to come up with a set of rules and customs like these
at the beginning of a project. If you allow yourself free use of all of C++'s
features in a large program, you will run into compiler bugs and weird
interactions between features, and the program will be hell to debug. On the
other hand, at the beginning of a project is the worst time to have to decide on
such rules, since it is when you know the least about the problems you will run
into.
Thinking about things like this makes me say "C++! Aargh, what a horrible
language! I will confine myself to Java, Python, and snippets of C henceforth!"
But then I look at the system my company builds, which involves some big-time
hairy distributed programming, mostly in C++, and compare it to a similar system
written in Java, and jobs dominated by interprocess communication run thousands
of times faster. And then I get all tossed up and conflicted and have to go
write some EMACS macros until I feel better.
--Carl Feynman
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT