From: Richard Loosemore (rpwl@lightlink.com)
Date: Wed Feb 01 2006 - 17:40:39 MST
My answer: none of the below.
For what I want to do, I need to build my own language. It is not easy.
Problem is, I cannot imagine being able to do it in any of the languages
you mention, and I have had too much experience of many of them.
You forgot to mention occam. Wicked language, but also wickedly
beautiful. One of the closest for what I need. Give me a cross between
Smalltalk and occam and I will be half happy.
Richard Loosemore.
Kevin Osborne wrote:
> without putting a fire under yet another religious programming
> language 'discussion' of attrition, I have what for me is an important
> question in regards to AGI development and seed developer syllabus:
>
> what programming language are we going to code an AGI with?
>
> when answering this question I probably want to dismiss convoluted
> combinations of systems, specialist languages/compilers that may
> (already?) be developed for AGI purposes and focus on:
>
> what's the best language to develop the AGI workhorse code in?
>
> 'workhorse' here means the code that will bridge the gap from the
> not-so 'intelligent' systems we have now and be able to bootstrap a
> higher semantic-language/instruction-set that will be part of the
> first steps towards an AGI.
>
> Here's a hopefully not-too-biased critique-that-invites-critique of
> some of the choices as they stand:
>
> C: I'm separating this from C++ as, well, most of the crack C
> programmers I've worked with view C++ as some kind of leperous cousin;
> they're able to make a host of criticisms of C++ in contrast to C but
> I'm not one to repeat them succinctly I think. In summary;
> positives:
> - it's the fastest; without question. It also runs on every board on
> the planet. There are a host of _great_ tools and compilers from the
> likes of GCC, Sun, Intel, IBM, HP etc. If you want to write your own
> OS kernel then you'll be doing it in C.
> - the #1 choice for RTOS. if you want it to run real-time, it'll be in
> C. I''ve personally had exposure to the VxWorks and Nucleus hard
> real-time systems and a soft real-time Linux (Monta Vista). Even if
> don't end up with
> kernel=observer/ego/consciousness/insert-your-term-here, going
> real-time seems to be an intuitive requirement for replicating a range
> of faculties. That said, real-time code is very limited to what it can
> do; it runs out of puff pretty quickly when climbing the OSI stack.
> - Macros are a great language feature, and can provide some of the
> extensibility and run-time switching needed.
> - great debugging tools and lint collectors like Purify that can
> pretty much guarantee against a number of errors like memory leaks and
> overwrites
> negatives:
> - plumbing code. it just plain sucks to have to call memset, malloc
> and free everywhere. #IFDEF may be damn useful but for me is ugly as
> hell
> - complexity/productivity. add all the plumbing code in; the need to
> track and free all your resources; macros that obfuscate recursive &
> often cyclic function calls to n levels; the need to dick with your
> defines both in the code and in the compiler, and the flag mess that
> ensues when you are linking against every man and his dll and you end
> up with a language great for low-level tweaking of the cpu instruction
> set and a morass once it scales that eats huge amounts of programmer
> time dicking with the maintenance of flags, variables and
> linker/compiler bleats. this inevitibly sucks large amounts of time
> away from higher-level functional work, especially during integration
> with other people's code. I'd posit it as a given that we are going to
> have to write more higher-level functional code than for any other
> project ever attempted. To code the capabilities and faculties of
> smart human is going to be a ridiculously huge endeavour. And once our
> boy is smart enough he'll be rewriting himself bigger and bigger while
> rewriting our code smaller and smaller. we just need to write
> something big enough so that he has the capability to do so.
>
>
> C++: the current language of choice for all large critical systems
> worldwide. The OSes are written in C, but the apps are in C++. When
> your plane lands, it's C++; when the latest NASA space-gadget bleeps,
> it's C++. The vast majority of apps that run global infrastructure are
> in C++.
>
> positives:
> - first things first; every VM and interpreter of note for the
> bytecode/interpreted languages is written in C++. A Java programmer
> bitching about C++ is like a hand bitching about it's forearm. If you
> want to hack your own special JIT or JVM, you'll need to be doing it
> in C++
> - Most of the RTOS vendors provide C++ APIs; so real-time application
> development is available (for a cost)
> - There's a larger body of support libraries available than for C when
> it comes to higher-level functions; the STL is a great example
>
> negatives:
> - as noted in one of the posts above, the toolset is awful in
> comparison. g++ is gcc's ugly cousin. linker errors, especially with
> STL code, are even more convoluted than C.
> - complexity/productivity. template soup is a great example. and yes,
> it still has pointers and memory housekeeping requirements, and yes,
> any plumbing work that is programming-language specific is a negative.
> Yes, some programmers thrive in this enviroment; however it is
> defnitely not competing when it comes to the RAD qualities of say,
> Perl or (gasp)VB.
> - Microsoft are dumping C++ like a brazilian baby. For all their
> faults, MS are a cluey bunch, especially when it comes to developers.
> They've got to have seen something plenty nasty in the bathwater to
> eat the cash-outlay gobstopper that is C#/.NET
>
> Java: The contender to replace C++ pretty much; the guys behind the
> language came out and said that they created Java to put the kiss of
> death to Bjarne's creation. This puppy is running some crucial
> high-load apps now, especially in finance. Also becoming the app layer
> of choice on mobiles through I doubt that's relevant here.
>
> positives:
> - a memory managed language; less programmer time spent playing
> nursemaid to an incomplete toolchain.
> - APIs/Libraries/Tools. The core API is simply enormous; if you want
> to do something, think of a class name that fits, and it'll probably
> be in the VM already. What isn't in their yet is probably either in
> the JSR's, sourceforge or IBM. Ant and JUnit(stack, incl things like
> HTTPUnit & JCoverage) are truly revolutionary in the tool space. They
> make makefiles and test stubs look archaic.
> - developers. every tertiary institution on the planet is pumping them
> out like sperm. we can debate their veracity, but the simple fact is
> most coders (of _any_ langauge) couldn't give a rats' about coding an
> AGI so having a deeper resource pool has got to help
> - reflection. run-time introspection, querying the classloader etc.
> gives more flexibilty than most strong/static typed languages
> - remoting. RMI/EJB have their issues, but you have a distributed
> systems stack in the core API. CORBA for C/C++ is an inferior
> (supported) subset.
> - price. it's all pretty much free as in beer, and free as in open
> source otherwise, apart from the spec. this _does_ matter; thirty
> C/C++ VxWorks/Metrowerks/ADS developer licenses would sting a pretty
> penny.
>
> negatives:
> - slowness. Now, this is historically overblown, especially in
> relation to the original GUI (remember applets? anyone?) and I/O
> impementations which have either been superseded or obseleted. Having
> had a look at some of the Sun source code, their C/C++ programmers are
> kickass (think Solaris). They've spent years refactoring every
> bottleneck and apples-for-apples underperformer in comparison to STL
> C++ until the difference is often negligible (check their marketing
> 'fact'oids). And for performance over a longer run, the application
> servers with thier hacked JIT's and pre-loaded code means that Java
> gets quicker the longer you run it (discounting any leaks, which are,
> sadly, still present, though much reducied in comparision to early
> JDKs). Another thing is that slowness seems to pretty much be a
> non-issue where AGI development is concerned; by the time we finish
> hacking at the thing the hardware and tools will be generations
> better. You either need real-time; or you let Moore's law do your work
> for you. My Java apps from 1998 fly on newer RAM-stacked hardware.
> - strong+static typing. my feeling is that writing on-the-fly runtime
> customizable code is going to be needed to replicate what a brain can
> do. Reflection helps but isn't enough; Java is a little too
> monolithically structured when compared to something like Lisp; the
> code is very homogenous, and doesn't seem to have the agility to adapt
> well. I think this is somewhat intended to stop migrating VB
> developers from deciding they now want to be Perl programmers but it
> doesn't aid in dexterity.
>
> .NET/C#
> you can pretty much replicate everything said for Java here as it's a
> flat ripoff; that's why I think Sun had no qualms ripping off ASP and
> calling it JSP.
> positives: they've learned their lessons from Java's mistakes; most
> things are less broken in the IL and the CLR. It's early days though
> and some of the apps I've seen behave atrociously.
> negatives: price; no option for CLR hacking. And it's got to be said,
> MS are evil bastards; trying being a chair in Steve Ballmer's office,
> let alone Netscape, Sun or Real.
>
> Perl
> OK I'll state my bias here; I've clearly coded in most of the others
> previously mentioned but Perl took my commercial programming virginity
> - and no, not doing CGI. Perl6/Parrot, while unfinished, seem to me to
> be pretty damn compelling. Once they have Parrot out with plugins for
> Lisp/Haskell/Java etc they'll have a pretty damn decent alternative to
> .NET. and having regex support within the syntax is just plain right.
>
> positives:
> - libraries. CPAN is huge; there's a module for most everything you
> can find in the Java API and plenty else besides
> - speed. competes tidily with C++, especially in batch processing.
> - typing. weak+dynamic. Perl doesn't care what it is or where it came
> from or what you're trying to do with it. 'use strict' can tighten the
> belt if needed for debugging. the auto/dynaloader magick allows
> run-time composition and execution of completely new
> functions/classes. The things the monks and their kin can do with this
> language is spectacular in a very scary way
>
> negatives:
> - oo. people knock their ISA implementation as a bolt-on. has always
> worked fine for me though. but it's definitely not as structured as
> say Java
> - complexity. weak+dynamic gives bad programmers license to kill. some
> perl code is unmaintainable. some wizards also take perverse pleasure
> in writing incredibly obfuscated code, unmatched outside of the
> functional languages I expect
> - toolset. perl is, well, fractured. it's a bit all over the place.
> you can get most anything to work, but just about everything is
> idiosyncratic as hell. Perl6/Parrot should put some kind of nail in
> this, but you never know with these crazy Perl nuts
>
> Lisp
> I have no sodding idea about Lisp apart from doing some reading
> recently and downloading a common Lisp compiler. That said, a good
> portion of the brightest minds in programming reserve a special status
> for Lisp.
> positives: functional/macro language right? good for self-evolving code
> negatives: Lisp already failed as the AI coding language of choice.
> Quibble all you like but it's 0 for 1, and AI Winter and the decline
> of Lisp seem interwined. Common Lisp doesn't even come close to
> matching the breadth of the bytecode-based APIs.
>
> Candidates dismissed for discussion, and why:
> (these langauges seemed to me to have no standout qualities that
> belied their shortcomings; and basically they just don't compete in
> the same league as the heavyweights)
> Pascal/Delphi etc: subsets of C/C++
> Python/PHP/Ruby: subsets of Perl/Java, with piss all supporting
> libraries for non-web applications in comparison
> Haskell or functional-language-of-choice: Useful past the bootstrap
> level, and mixed in via say Parrot could be useful; but underweight
> for workhorse work in terms of developer-space footprint
> ADA/Fortran archaic-failed-language-of-choice: nothing better than Lisp.
> Assembler/Machine language: all great, until you leave x86 to go to
> Cell chips; then you're stuffed
>
>
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:55 MDT