Orthogonality is a much-touted philosophy of language and system design. To boil it down: orthogonal design means that features multiply each other's utility, and overlap as little as possible. Given a set of carefully-crafted orthogonal features, you can enable a wide variety of possibilities through combining those features. In theory, this means that you can have a small and simple "core", which enables a rich environment. Languages at far end in this direction of design would be Smalltalk and Scheme.
This seems really nice, and everything seems comprehensible and simple. Except, if you actually work with Scheme code that does something useful, it's not particularly simple. In Smalltalk it is very common to encounter Ravioli Code, a kind of anti-spaghetti code that seems to be nearly as incomprehensible. Idealists of this direction of design end up with weird concepts like Paul Graham's 100 Year Language where he speculates on designing a language without built-in integers, because integers can be derived from simpler concepts. Only a mathematician would call that elegant, of course -- but even they are lying when they say that, for even the most fundamentalist mathematician does not use the Lambda Calculus when balancing their checkbook.
Orthogonal design allows unbound creativity. Anyone who tries to be creative knows that creativity without bounds is very hard to handle. Bondage is still worse, but constraints aren't all bad.
So, on the opposite side of the spectrum from the orthgonal languages are languages with non-multiplicative features -- features that are mutually exclusive, or linearly enumerable. Here lies PHP (which I started thinking about from this discussion).
And there are real benefits to that position! One example of this design in PHP is the lack of objects in the standard library. Instead it is one very long list of functions. If you want to do something with the standard library there either is a function for doing it, or there is not a function. If you want to see what you can do, you can just scan through the index.
This is literally what beginning programmers do (and mediocre experienced programmers). They read lists, and this is very productive for them. I'm not a beginner, but I still like lists too. You find what you want, or you don't; and if you do, you probably find an example close to what you want to do. Or you don't, and then you have to think and be creative, but for some software you don't really want to be creative, you just want to get shit done. PHP is all about getting your shit done. You go beyond that and PHP is not that satisfying. But man, when you are coding PHP you can practically fall asleep and your fingers will still be flying, banging out code -- it feels so productive. If you are a fast typist and you have a loud keyboard this is a very good way to impress your coworkers.
If you feel code is a liability you will not be so impressed by the large number of characters produced by a PHP programmer. Oh well. Because the PHP programmer -- particularly the beginner, but this can even apply to the advanced programmer -- feels very satisfied, there's lots of positive feedback. They are not using the values of pretentious software engineers.
So, that's why PHP is so popular. And it's entirely deserved. And Basic before it -- another language that seems so painful because of the lack of orthogonality, but that is both its curse and greatest feature.
The language that got me thinking along these lines wasn't actually PHP, but Django templates. I was looking at them, and they have no expressions, no boolean operators, nothing complex, nothing you can't process with a regular expression. And as a result if you look at the documentation you see an enumeration of everything you can do. Everything. That feels uncomfortably constraining to me. But to someone who doesn't program that would feel very comforting. And that's the whole point of that language; it wasn't written for me. And I guess PHP wasn't written for me either, but I already knew that anyway.
Niggle: Django lets you write custom tags and filters in Python to extend the template language. I like your angle on it a lot though. Having all of the functionality laid bare before you (we've always deliberately tried to avoid letting the template language become another programming language) has a definite advantage both in dealing with non-programmer designers and in encouraging application logic to stay out of the templates.
Custom tags don't really change anything -- unless you created a tag that eval()'d its content. Custom tags extend the list of constructs, but it is not the template programmer who is extending anything. Custom tags seem more like a localized or app/site/domain-specific set of constructs, and then you have the main Django tag list and the local tag list, but they are still lists.# Ian Bicking
+1. Without lists most things feel like you've got tunnel vision-- add in inherited project/framework or critical bug anxiety, and kiss the 'curl up with a good algorithm' vibe goodbye. Give me the table of contents, index, glossary. :-) I expect this is one of the major reason folks hate wiki's and love weblogs. Nothing so comforts a newbie as dir(), auto-complete and an object diagram.
Are you saying for example, instead of:
nl2br() atob() footobar()
We have string.replace(in, out)?
I'm not sure how that seperates newbies from pros, when I want to do something in Python I still dir(), check docs, google... instead of nl2br() I find replace() (Of course this is a retardedly simple example, but still...)# Brett
That's actually a very good example, because it's truly at the level where those beginning PHP people are enjoying PHP. Sure, a_string.replace('\n', '<br>\n') seems easy enough to me and you, but has a bunch of details as a prerequesite, details that get in the way of a beginning programmer coming up with that expression on their own (or at least, it would be a real and true programming task for them, where it's just an idiom for you or me). Obviously a more experienced PHP programmer could come up with that on their own, but they are already hooked at that point. (And at the same time I think there is a substantial group of PHP programmers who do not completely understand the inner workings of something like nl2br()).# Ian Bicking
Combined with the built-in tag/filter/model/view documentation in the Django admin, this really is an enormous timesaver for handing off finished apps to clients or non-programmers (like me). When we add a new tag or object to a client app, all I have to do is send the client developers a link to the docs and they know exactly what they need to add to the templates. And the best part is, our programmers move on to doing something else productive instead of lingering in the muck of helping the client (or me) make it "look right" in the template.
When you're a solo programmer I can see how it would be great to have total control and flexibility of a real programming language in the templates. But when you're handing off to someone who's not a programmer it's a killer feature to be able to control what they can and can't do without having to explain it to them. Just implement, handoff and get your shit done.
I totally agree with you. Adding on...
If you ever try a templating language that is Pythonic and try mixing up with CSS/HTML you are in for big trouble, as and when the designers do those little adjustments, the damn Python indentation gets screwed up. It can be a pain fixing them up# Shah B
I think you've got one reason why Smalltalk bothers me. Orthogonal sounds good in practice (and does have some real value), but most people (outside maybe mathematicians) don't think that way.
For example, all human languages that I know of are decidedly non-regular and non-orthogonal. Made up ones (Esperanto) haven't been a success. Or, nearer to Computer Science, early RISC processors emphasized orthogonality (which does have value for pipelining and compiler writers), but all the surviving ones (PowerPC, ARM, etc) have bulked up considerably.
Good grief :-)
What a throwback!
Programming isn't assembling lego! You can over-do anything I guess, but I would rather learn how to mix and match five orthogonal functions than work out what 5**5 = 3125 separate functions do.
Hmm, can't comment on PHP and Django though, I don't use them.
- Cheers, Paddy
Complete Orthogonality is like binary system but it is more human to use decimal ;)# dado1945
With an orthogonal design, your solution space is regularly structured into n dimensions. Makes live really easy if you have a huge problem space to match it.
But beginners have a rather small problem space, and for the even smaller number of solutions they need to tackle it, being forced to think in multiple dimensions is just overkill, apart from the fact that most of us humans prefer not to be bothered with too many dimensions anyway, so the flat list (n=1) can hardly be beaten in terms of popularity.# anonymous
Orthogonality is not just (rightfully) pretentious. It's also complex in itself and difficult to do right. Although mathematical analogies appear to be tempting, there is a huge difference between mathematical and programming spaces - programs do not live in a single space and so there are no 15 universal axes along which you should be able to modify your program. I would rather compare a program to a bunch of pipes connected with junctions. At each junction orthogonality helps to rotate the pipes in any direction you like, but as soon as we live in three dimensional space, there is hardly any use of more than two axes _at_each_junction_.