Slashdot Mirror

*imagined response from a new programming language writer*

Sure, they've already used A, B, C, D, E, F, and assorted appendages (A+, B++, C#, C--, C++). However, mark my words, G will leave a different legacy. G (for generic) will be the be all and end all language.

G will be able to compile for binary, trinary, and anything ending in -nary with the change of a single number.

It will have solved the problems of security in that no buffer overflows will be possible, no memory management will be done by hand, and the computer even correct code for transactions. Any program which is insecure will be fixed automatically based on the logical structure and purpose of the program.

Mathematical equations merely will need to be entered in and automatically solved.

G will be faster on parallel architectures and will even do your dirty laundry!

Now you see why G needs to be made. A, B, C, D, E, F, and assorted appendages just can't do it exactly right.

*A few years later a new guy steps onto the scene*

G is so outdated and full of holes. It doesn't do X, Y, and Z. It doesn't deal well with the new data storage equipment. It's security started off good, but after they found those few gaping flaws became a joke.

What we really need is a new language. Let's call it the H programming language.

I can vouch for that. Linux has been in Wall Street for a long time: it just sits there quietly working without fuss. For those interested, Morgan Stanley funded the development of a new language A+ which is similar to APL. It's also GPLd.

Morgan Stanley's A+ development environment has been released as OSS, http://aplusdev.org/.

It was originally considered a competitive advantage. It's an APL like interpreter, with many interesting ideas in it. Originally conceived in the late 80's, it allowed many people to develop financial applications without having to first master C, Sybase, and Motif/X11.

I'm sure many who have never done a reasonable survey of programming languages will jump all over it being a "dead" language. I personally learned a lot both from the language and the underlying implementation. There is the work of many very talented developers available in the interpreter and the supporting libraries. Many business critical applications were written in it and continue to run. I've been able to use techniques I've learned from that environment in my later programming projects in Perl, Java, ...

It's not easy to convince companies to open source projects. This release wouldn't have happened without the tremendous efforts of Brian Redman. I believe it cost him quite a bit in political capital.

K is mostly written in itself and you can freely examine that code from inside the environment. There is a C part to it, but I am not sure you'll be able to make any sense out of it if you are not used to APL-like code density. To put it simply, the C part of K is written in K implemented in C macro language. This was generative programming way before it was officially invented. To get a taste of what I am talking about, look at the source of A+ at

http://www.aplusdev.org/

(A+ is a precursor language to K, that Arthur wrote at Morgan Stanley. It is a lot more APL-like than K)

K has been known to beat carefully written C code on a few ocassions and here are some possible explanation (It is weird, considering that K is itself written in C)

a) K uses bulk allocation. The smallest memory unit it uses is a VM page. To achieve the same result with C, you will have to hoist all your mallocs to the upmost level and do all your own memory allocation - this is not a very common thing you see.

b) A lot of C code uses stdio here and there. K's native I/O mechanism is memmap (This is another reason why the Bell labs benchmark rubs K the wrong way - it uses stdio (and loops like Jason said before))

c) Do not underestimate the power of lambda/delayed eval combined with JIT compiler. For example, it is possible for the K runtime to detect an inverse function to a given function and drop both before evaluation.

d) K tends to produce code that is nearly branchless, eq not a single explicit loop in the whole of kdb! This is very nice on your memory subsystem. In general, kdb's got to be world's only IN-CACHE db (at 150K, the whole thing tends to stay cache resident at all time. I checked -
the code had virtually no trace. The data trace is extremely linear due to the embracing of inherent temporal ordering in relational data. This is very unusual - for example Oracle is all over memory and routinely trashes 4MB caches. How is that for a paradigm shift if I tell you that relational databases are actually among the most vectorizable/paralleralizable codes out there?!? They ran the wrong software on those Crays...

I'll second that.
Morgan Stanley has a GPLed implementation for most Unices called A+.
For a reference, pick up APL: the Language and its Usage, Learning APL: An Array Processing Language,
or Ken Iverson's A Programming Language, from which the name of the language is derived.
A modern variant which uses ASCII characters is K. Free as in beer, for FreeBSD, AIX, Linux, Win32.

More and more, Perl seems to resemble APL.
The emphasis on one-liners, TMTOWTDI, VHL monadic or dyadic operators, and reputation as a write-only language.
Larry Wall seems to have the goal of evolving Perl into a natural language or something equally complex.
Non-ASCII characters seem like a mistake to me as well, Unicode support is far from universal and it introduces unnecessary complications, especially for parsing Perl programs.
At the very least, there should be some alternate form of ASCII representation, possibly similar to Morgan Stanley's A+.
Most modern APL style languages use ASCII characters for precisely this reason.
If using a tool is too complex, people will look elsewhere.