This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Programming For Klingons
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
The Spanish for "business" is negocios, which I like. The French seem to use the rather straight translation le business or the more formal affaires. Do the Spanish tend to see a business deal as primarily about the negotiations? I don't think so - I'm no big fan of the Sapir-Whorf Hypothesis (something I first heard of as the "Whorfian Heresy", which might give you a clue as to the opinion of the linguist who I was talking to).
I think there's another Whorfian Hypothesis, that Klingons would have a different approach to programming; in their version of Python, del would become obliterate, remove would become abduct-and-return-for-questioning and there would be no co-operatively multi-tasking systems; everything would compete aggressively for resources. There's a whole blog entry in there, about the co-operative environment within computers but the Darwinistic competition outside... though not today.
But enough of such babblings; the Sapir-Whorf Hypothesis does apply, I think, in the area of programming languages. Most programmers I know tend to think via a particular programming idiom[0]; that is, they tend to address a problem in the ways that their main languages allow. It goes further than languages too; as a Unix-esque person I'll tend to think of networks of processes piping stuff to each other. A Windows developer might tend to see everything in terms of COM objects. And so it goes.
I'm not arguing that a programmer is blinkered by her choice of language; that would be extreme and I don't believe it to be true. What I do think is that different languages afford different ways of doing things (and I mean afford in the Heideggerean sense[1]; they make various possible ways to solve a problem either easier or harder. For example, any C programmer who's knocked around a bit will have dealt with a fair number of C strings and the complex and tedious code that often attends them. Therefore solving a problem in a string-oriented manner might not be the first approach they'd take. Conversely, someone whose world revolves around Perl (or Python) would consider complex string operation as easy. One of the biggest differences is probably in the nature of the data structures that a language supports. I find myself constructing far more complex arrangements in Python than I'd ever have considered in C, simply because the language makes it easy and safe to do so; the potential for error is vastly reduced.
As someone whose predominant language is Python these days, I use mapping objects and lists far more than I ever would have in my C days. I was a good C programmer; no corner of the language was a mystery to me and I could generate or parse obfuscated examples with the best of them. But far too much of my time was spent in (a) being clever for the sake of it and (b) writing the same code over and over to address the same mismatch between the essential high-level-assembler-ness of C and the abstractions that the project at hand actually required. One day, deep in a debugger, I realised that pointer errors just weren't fun anymore; probably the start of my long and all-too-slow growing up from wild hacker to something that might one day be called "software engineer".
But let's take one particular language vs. language debate familiar to most Pythonistas; that of C++ vs Python. For me, the single biggest difference between the two is not their abilities in the abstruse and specialised areas like metaclasses, nor the particular semantics of their class and object mechanisms, but the low-level and almost invisible (to a Python developer) issue of garbage collection and object disposal. It's this, I think, that has at least the potential to make Python such a productive system; the removal of the C/C++ need to continually concern oneself with the question of who is to freeallocatedmemory[2]; that whole notion of memory "ownership" that the programmers have to track themselves through comments and documentation[3]. Sure, if I'm going to think carefully about the nature of my data structures I may need to choose to use weak references at time, or use del as appropriate, but even at its worst there's nothing like the weight that's imposed on someone thinking in the medium of C++.
[0] That is, they think in terms of what a language can do rather than in the specific details of its syntax. I'm not aware of any Python distributions that can be cranially installed (yet). [1] Readiness-to-hand or utility of tools and objects, to be a little more specific. [2] See the section "Automatic Transmissions Win The Day". [3] Before a flood of C++ enthusiasts bombard me with links to articles like this (which argues that explicit memory management a feature, not a defect) or this (which proposes solutions to the issue, written in more C++), let me say that (a) it's only a blog entry and you're free to disagree and that (b) the wealth of results that a Google search for "C++ memory management" returns is an illustration of how big an issue this is. :)
Previous Topic
