Just what is a PinkyAndTheBrainLanguage? Just what you'd expect -- one that tries to "take over the world!!!!!" (maniacal laughter)For the uninitiated, see PinkyAndTheBrain
Some languages provide little more in the language definition (including the standard libraries, for languages which come with such) than basic types and control structures. C is a good example, with primitive I/O (suitable for low-performance file manipulation and console I/O, but sorely lacking for anything more than that) and memory management, but little else in its standard library. The extreme of this was Algol, which had no I/O support in the language -- which meant that it was easy to port, but no useful program could be written without invoking non-portable features.
Other languages, the subject of this page, take the opposite approach; and try to provide the programmer with everything. In some cases, they merely abstract the underlying system; in other cases they attempt to impose their will on the underlying system. While the latter makes for greater portability, if a particular machine doesn't mesh well with the model mandated by the language, pain and suffering results.
Examples of PinkyAndTheBrainLanguages include:
JavaLanguage. This one isn't too bad, except that Sun seems to have decided that nearly every problem domain known to Man belongs in the standard library. For some areas which are well-standardized (such as networking) this makes perfect sense. For others... let's just say that Java fans who used to point out the immensity of the C++ standard library don't seem to mention this anymore...
AdaLanguage. The ultimate PinkyAndTheBrainLanguage. Imposes its own threading model on the underlying system (one which is fairly nice, at least from a theoretical point of view). Highly portable because of this, assuming the hardware/OS cooperates. Many OS's don't. A good language for embedded systems (especially mission-critical ones), but you wouldn't want to write your enterprise apps in it.
SmalltalkLanguage. A language highly integrated with its environment, which is probably both a plus (it had a damn good IDE before the term "IDE" even existed) and a minus (some of us still like vi and make...) Like Java, prefers its own graphics libraries/toolkits to whatever the underlying OS provides. Unlike Java, the portability gain is a bit questionable, as Smalltalk still seems to have quite a few mostly-but-not-quite-compatible dialects out there... Compatibility between dialects and portability are two different things. SqueakSmalltalk has been ported to many more systems than Java has and Squeak code runs identically on every one of them.
LispLanguage. One of the first languages (along with Forth) to be highly integrated with its environment. Er, shouldn't that be "one of the first languages to have an environment highly integrated with it"?
PerlLanguage. Though maybe this is more an instance of PinkyAndTheBrainLanguageCulture?, it's really amazing what you can find on CPAN these days. Plus there are innumerable hooks into the various nice things about Unix, and even limited support for equivalents in other operating systems (in the corresponding ports). "P.S. Perl's master plan (or what passes for one) is to take over the world like English did. Er, *as* English did... -- Larry Wall in <199705201832.LAA28393@wall.org>"
PythonLanguage. The language advertises itself as "batteries included" for all tasks... combined with ZopeApplicationServer, you have the whole client-server architecture for just about anything you could ever want.
Does ShellLanguage? (whichever one you choose) thus qualify for this quality? You could say that shell's 'CPAN' is all the command-line programs available on the standard (more-or-less) *nix-like system, and that 99% of it is 'hooks' into the programs provided by the underlying system. Maybe it has evaded notice because nobody (for various definitions of 'nobody') seriously thinks about porting shell scripts, because shell isn't a RealLanguage (for various definitions of 'real'). Come to think of it, C might qualify under the same terms: Its 'CPAN' isn't centralized but it is very real and absolutely huge, and it is commonly used as a thin layer over system-specific APIs.
No, I think PerlLanguage, ShellLanguage? and CeeLanguage are quite different. Although there are facilities for these languages for doing virtually anything that's computable, they aren't part of the language itself.