Symmetry Of Language

[By symmetry we mean something very similar to its meaning in physics. In physics, we can talk about the symmetry of space under the laws of physics, or the symmetry of the laws of physics themselves. In computer science, one type of symmetry is if the features of a programming language operate equally on all of the things in the programming language.]

A highly symmetric language is one whose syntax permits its semantics to be used to extend the scope of the language. This is a dramatically underrated - perhaps invisible - property to most language users, but an excellent way to judge the long term (non-marketing-driven) endurance of a tool.

Symmetry fights interstranglement (NeologismOfTheDay! - cf ExtremelyInterstrangled) because the more a language's syntax permits its semantics to be used to affect the language itself, the less need there is to define and name artifacts to augment the language's semantics. By reducing the number, complexity, and brittleness of consequently required plugins, environments, libraries, and other extrasemantics (NeologismOfTheDay tomorrow!), a highly symmetric language reduces the CostOfLearning it as well as enabling, by ReFactoring, this cost to be flattened over time.

That last claim is extremely dubious. A language that can affect even its own syntax and semantics would be quite symmetric, but imagine for a moment that you aren't the person making the changes - you're the person coming along twenty years down the line in a new generation of programmers, having given the language two decades for people to twist it to their own liking for individual projects. You don't see one language to learn. You see thousands. Only if people take specific efforts to fight 'ThereIsMoreThanOneWayToDoIt', or if there are some awesome RefactoringBrowsers that can easily help teach the languages in use, will CostOfLearning be maintained or reduced.

Implications:

Application of the language to its own components (strictly including syntax and semantics) seems to imply: HomoiconicLanguage (or at least a Homoiconic KernelLanguage), ExtensibleProgrammingLanguage, FirstClassTypes (if typed), FirstClassFunctions. An ObjectOriented language would need a MetaObjectProtocol. A modular language would need the ability to construct modules functionally (FirstClassModules). To affect semantics requires the ability to extend (if not replace) the language postprocessor pipeline (compilers, interpreters, optimizers, etc.) That just happens to get you AspectOrientedProgramming for free. To allow syntax manipulations to affect how one can import files and modules and such, one needs access to manipulate the linker spatially from within the code. And one, of course, needs a bootstrap syntax - something that has all the semantics for its own manipulation.

Some of these are KeyLanguageFeatures, but it is worth noting that most aspects of a symmetrical language - e.g. the semantics for everything that is NOT within the language itself - would simply be part of the base KernelLanguage. Issues such as whether a language supports mutable state and whether it provides for CallWithCurrentContinuation might be difficult or impossible to manipulate (though the correct set of initial language primitives may offer some ability to implement these features, or at least a good 80% solution).

Now for the Inevitable - People arguing about Symmetry as applies to MyFavoriteLanguage:

CeePlusPlus and JavaLanguage have almost no symmetry. RubyLanguage, on the other hand, is extremely symmetrical. PythonLanguage is not. Wiki is and Sharepoint is not. DotNet is and the infinite-GUID-based-arcana it replaced are not. -- PeterMerel

Hum, PythonLanguage not symmetrical? I have an impression it's quite the opposite. -- AnonymousCoward

I should have said, compared to ruby. I adore python, but just the fact that there are both list and array types is illustrative here. Is the language weakly typed or is it not? Syntactically sour notes - the __init__ mechanisms, the lambdas, and so on - have led to semantically sour ones - zope acquisition being the most strident but also the failure of stackless. And more little ones. What I'm trying to get at with symmetry is the notion that, no matter what you want to do, you do it exactly the same way, with the same syntax, as anything else. This is where I believe ruby excels. Another nice example is the fact that seaside doesn't provide a separate templating mechanism - because xhtml is encapsulated without trouble or expressive weakness in smalltalk itself.

Ruby has variables named "var", "@var", "@@var", and "$var", and the naming matters. I think calling Ruby symetrical is a leap, and trying to claim it is better than Python in that context is more language advocacy than fact.

As covered in TheProblemWithSigils, these critters are intentionally ugly. I agree they're not symmetrical. Neither, to my mind, is the whole attr_ thing. I'd rather the language use a macro preprocessor ... no I wouldn't. Anyway happy not to indulge in a language pissing match. MassiveMindshareMovement to ruby from the java, perl, smalltalk and python camps dooms python. Whether you mourn python or not is not a subject for civil debate.

I'd say calling Python doomed is pretty much straight out of the language pissing match playbook. Perhaps this page should be retitled? RubyIsSoVeryCoolThatAllTheCoolKidsUseItAndPythonJavaPerlSmalltalkAreAllDoomed sounds good.

In Python, methods are objects, with identity, type etc. In Ruby they are not. Python is much more symettrical in its handling of code-as-data. For example, to make x.y() available under the name "a" on the object "b" I just say: a.b=x.y . What is the equivalent code in Ruby?

[I know my way around in RubyLanguage and PythonLanguage. Maybe some examples of contrast in these two languages would help. They would at least help me understand what you mean by symmetry and lack thereof. Show me something you can do in Ruby that can't be done in Python. (And no, I'm not trying to start a language war.) -- ElizabethWiethoff]

I'd like some good/bad examples. I wonder if, e.g., the usual sub-languages for templating (generics) and typing (type annotations) count as asymmetries in this context. -- GunnarZarncke

Let's see if I have a handle on this:

In CeeLanguage, you have the concept that Everything Is A Function, except that this is actually not true. The operators are (mostly) infix, and parse differently from functions, and the compiler is allowed to know special (and restrictive) things about variables and functions. CeeLanguage, for this and other reasons, lacks this symmetry.

In ForthLanguage, you have the concept that Everything Is A Word, which is literally true. The operators receive their arguments exactly the same way that any other Word does. Operators are Words. Words that handle strings parse forward, but it isn't the interpreter/compiler that's doing that: the string manipulator itself is doing that as part of its execution. Nothing is "parsed" in any conventional sense; everything executes. While there are Words that do arcane things in their compile-time behaviors to enable [whatever] in the run-time behavior, those words still just execute. New Words added to the language/application (there being no real difference), just execute. There is no special syntax for "PERFORM FOO" or "CALL FOO" or "RUN FOO" or even "FOO()" - it's just FOO. And maybe some arguments, e.g. SNARF BIGGLE 6 0 FOO. No type checking or other "special knowledge" to restrict or constrict. The Word you just wrote is accessed and executed exactly like any other Word in the lexicon. ForthLanguage, therefore, has this symmetry.

The question does not seem to be "can I do in this language something I cannot in another," but rather seems to be "does everything this language does and everything I can do with it work the same way?"

Am I tracking? -- GarryHamilton

Yes, many thanks. -- Pete

Is symmetry a recognized word in this context or is this something you picked? I think 'orthogonality / independence of features' or 'consistency' or 'universality of principles' would probably have conveyed the meaning better. I don't remember what ProgrammingLanguageConceptsAndParadigms? called it though I recall it treated the concept. -- RK

It's what I called it because I don't know any better. If you can give a good reference to a better word for the job, I'd be both happy and interested in finding out more. -- Pete

Certainly. I suggest NeologismTargetedSynergesticValuePropositionTerminology?

I almost dare not mention it but is this related to HomoiconicLanguage? in the sense that a HomoiconicLanguage has to be a Symmetric Language?

I expect it would be the other way around. A symmetric language should probably be a HomoiconicLanguage at least in the underlying representation (in the sense of having an officially defined AST that can be constructed functionally), at least if its own syntax and/or semantics and/or code are to be among the "things" it can target for creation and manipulation.

A symmetry in physics is a transformation that leaves the system under consideration unchanged. So, for example, there is a time translation symmetry to the effect that systems will behave tomorrow the same way that they do today. If this use of the term "symmetry" is supposed to be analogous to that in physics, what is the "transformation" that is being applied to what class of systems?

At a guess, based on the topic line "In computer science, one type of symmetry is if the features of a programming language operate equally on all of the things in the programming language", this page discussess symmetry over the concept space - i.e. the rules of the language applying equally to all concepts supported by the language. The rules will apply the same for that value/object/etc. over there as they do to this one. This is as opposed to having a variety of spurious exceptions-to-rules, such as not being able to apply functions to lists of types, or having 'special' types like 'int' and 'float' that break the manipulation and operator rules and inheritance rules of all other types. SymmetryOfLanguage, in this sense, is easiest to obtain in simpler languages (EverythingIsa is pretty useful in achieving it).

That said, in physics there is a result to the effect that for any symmetry law there is a corresponding conservation law (time translation symmetry corresponds to conservation of energy). If it's possible, it would be interesting to try and push the analogy further and find a conserved quantity for a languages that captures the same concepts being discussed here.

I'm not certain. As a language designer, I can say that SymmetryOfLanguage doesn't require a conserved set of concepts, but it does require careful integration of every 'new' concept such that every rule applies to it and it applies to every other concept. Perhaps you can think of something. Is there some sort of 'spatial translation symmetry' for physics? If so, what is its corresponding conservation law?

Momentum.

JanuaryZeroSix

CategoryLanguageFeature