The idea that big, evolving systems are best built using two layers, one hard and one soft (see AlternateHardAndSoftLayers), implies that such projects will need two languages, one hard and one soft (where a Hard Language is what we usually call a ProgrammingLanguage and a Soft Language is what we often call a ScriptingLanguage).
This suggests that attempting to invent languages to build big systems is folly; rather, we need to develop pairs of languages, that work well together - SymbioticLanguages, if you will.
Are there examples of such symbiosis?
Perhaps the better requirement is a standard ForeignFunctionInterface or protocol (such as Corba or pipes), so that any conforming soft language can interoperate with any conforming hard language.
- Unix has CeeLanguage as its "hard" language and the UnixShell language as its "soft" language.
- Of course, nowadays there are much more "hard" and "soft" languages available for unix, but this separation used to be pretty clear (and was officially condoned by its designers). Both languages were designed on unix.
- C (including C++) is still pretty much the de facto hard layer for Unix. You have many more choices for the soft layer; including Java, Perl, Python, the traditional shells, etc.
- On the CommodoreSixtyFour and the AppleIi, BasicLanguage and AssemblyLanguage were soft and hard layers.
- This was full recognised with BbcBasic which as well has using one of the higher level BasicLanguage variants of the era had a built in inline assembler.
- On OS/8 (PDP-8), RSTS/E (PDP-11), and TOPS-20 (PDP-10), BasicLanguage and AssemblyLanguage were soft and hard layers.
- In ControlProgramForMicrocomputers? (CP/M), BasicLanguage and SUB files (like DOS batch files) were soft layers and AssemblyLanguage was the hard layer.
- In MsDos, BasicLanguage and BatchFiles? were soft layers while AssemblyLanguage, CeeLanguage, and PascalLanguage were hard layers.
- In the IncompatibleTimeSharingSystem, MacLisp was the soft layer and AssemblyLanguage (via the MIDAS assembler) was the hard layer.
- In MVS, RexxLanguage was a soft layer and AssemblyLanguage was a hard layer. (Whether JCL was a hard layer or a soft layer is left as an exercise for the reader.)
- In VMS, soft layers were BasicLanguage and DCL while hard layers were FortranLanguage, CobolLanguage, CeeLanguage, BlissLanguage, and AssemblyLanguage.
- In GNU Emacs, EmacsLisp is the soft layer and CeeLanguage is the hard layer.
- In the LampPlatform WebDevelopmentToolChain, PhpLanguage is the hard layer and SqlLanguage is the soft layer. Or vice versa.
- In the MicrosoftWindows world...
- circa 2005, C/C++ is the hard layer, and DotNet (take your pick) the soft layer. Or, VB.NET & C# are hard; C/C++ very hard; various scripting .Net languages soft -- JscriptDotNet, PerlLanguage & PythonLanguage.
- before this: VbClassic hard, C/C++ very hard, and various ActiveX (COM) scripting languages could be used for soft layers -- typically JavaScript and Visual Basic Scripting.
- In JavaPython, you can use PythonLanguage as a soft layer and JavaLanguage as a hard layer.
- The first system I used like this was a Honeywell 316, where the soft layer was in BasicLanguage and the hard layer was compiled subroutines in FortranLanguage. -- JohnFletcher
- In JavaServlets, JSP and XML are (sort of) soft layers and JavaLanguage is a hard layer.
- LispLanguage is a hard layer and application specific syntax implemented using LispMacros is a soft layer.
- ForthLanguage is a hard layer and application specific syntax implemented using ForthImmediateWords is a soft layer.
- C and Haskell can work in a very PB&J sort of way, though many would say that's alternating diamonds and granite instead of crust and cheese.
- C, Python and Guile are an inherently inter-supportive mix, at least on a Unix type styem. C is hard, Python and Guile are both soft with the latter soft enough to be a good user-end scripting interface (particularly if your target audience has any experience with AutoCAD, lispy quest scripting for game engines, Emacs, etc.).
Many scripting languages have well defined C APIs, and are designed either to be embedded into a C program, or extended with dynamically loaded C libraries, or both. EmbeddedLanguages include ToolCommandLanguage and LuaLanguage. Languages designed with dynamic extension APIs include ToolCommandLanguage, PythonLanguage and RubyLanguage.
Most, if not all, implementations of CommonLisp provide a foreign function interface ("FFI") which can be used to call C (and sometimes C++ or Fortran) functions from Lisp, and vice versa.
Perhaps EverythingIsSymbioticWithCee??
In the Windows world VB + C++/ATL/COM has proved very powerful. Now C# + ManagedC++ appears to be a great way to mix legacy or performance-sensitive C++ code into the softer .Net world.
HtagLanguage paired with DelphiLanguage provides such a pair as well.
Q: Are JavaLanguage and ExtensibleMarkupLanguage symbionts? Certainly RelationalWeenies lump them together for abuse. They seem to travel and propagate together very often. Why might this be?
Possible A: Symbiotic languages have to live in the same environment and each do things the other doesn't do well. Java and XML both live in the same target-space: distributed, cross-platform applications. They both target the AverageProgrammer by building off of known quantities: CeeLanguage and HyperTextMarkupLanguage. If it's true that XmlIsAPoorCopyOfEssExpressions, XML makes up for Java's limited FunctionalProgramming capabilities. And Java's object model, while perhaps limited, can be a convenient way to wrap XML's structured data together with code. Thus, symbiotic. Any thoughts?
Another possible A: Just a coincidence of timing -- both became popular at about the same time.
I vote for the first bullet above: "A HardLanguage that supports flexible MetaProgramming should be able to perform both tasks."
IMO, there is a widespread opportunity to use two symbiotic languages, partly inspired by TgpMethodology. See: OfficeInfotechSymbiosis.
-- EdwinEarlRoss
Symbiotic Languages