in reply to (OT) On Orthogonality

When I am talking about a programming language, what I mean by orthogonal is something close to "tiny". C, for example, is really an itty bitty language. This doesn't mean that you are rigidly set in the number of ways you can do something - it means that you are given the most basic tools, rudimentary access to things, the compiler / interpreter assumes nothing. You are given tight control over every aspect of the problem - and are expected to maintain all of those little aspects.

An orthogonal language doesn't "double up" - meaning that a tool does one thing, well. You don't get eval, AUTOLOAD, and the like. You get variables with strong typing, some mathematic operators, and strings are really arrays of characters, cause the compiler doesn't have a "string" type, but a "char" type. That is the essence of orthogonality - nothing but what you need, or what can build what you need.

Cheers,
Erik

Replies are listed 'Best First'.
Re: Re: (OT) On Orthogonality
by mr_mischief (Monsignor) on Apr 16, 2002 at 19:03 UTC
    You could also have orthogonality by having a string type and no char type. ;-) I agree that a smaller language is more likely to be orthogonal and vice versa. There's a high degree of correlation there, but it's not a rule without exceptions. Orthogonality, as I've seen it used, is often very generalized compared to the mathematical definition. It doesn't only mean that the ways to do different things are independent of each other's results (which would be orthgonality specifically of semantics), but also that the language syntax gives you building blocks which are similar in the amount of work they do per block and that there don't tend to be any single building blocks (constructs or keywords) that duplicate the work of a set of smaller building blocks combined in a specific way.

    I'd say that Perl is fairly orthogonal semantically, meaning that one operation doesn't generally effect the operations before or after it. The use of some default variables limits this a bit, but not much. Syntactically, I'd say that some orthogonality has been sacrificed for efficiency in both programmer time and in running time. There are some very big, powerful things built in which other languages would leave to be built up while there are other, smaller things which allow those big solutions to be built up another way.

    So, this is where I think there's much debate over what makes a language orthogonal. There seem to me to be two different ways in which a language can be called orthogonal, with some languages being further along one curve than along the other. Personally, I think orthogonality in a language is not necessarily good nor bad. Both types effect the efficiency of the language in certain ways. Both effect the programmer's expectations and the fulfillment of those expectations in some way. What's important is that there's a balance struck among the programmer time, system time, ease of beginners learning the language, ease of intermediate users of the language advancing their knowledge without too much surprise, and the other factors that make a language useful. As we all know, if a language is perfectly designed to follow one mantra, then only the most ardent followers of that mantra will use the language. As we also know, if a language makes a few compromises which make it useful in a general population of programmers for general tasks, then it will get wide use an perhaps even benefit from further refinement and support. Ever notice there are no domains called oberonmonks.org or srmonks.org?
[reply]

In Section Meditations