![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
haxhaxhax's journalLog in Create a LiveJournal Account Learn more
| You are viewing haxhaxhax's journal Log in Create a LiveJournal Account Learn more | Explore LJ: Life Entertainment Music Culture News & Politics Technology |
|
|||||||
 |
|
|
|||||
|
hax!  So the WAEC published the results of the referendum at http://www.waec.wa.gov.au/elections/sta I overlaid the data on a map of electoral boundaries of the Perth metro area (http://www.boundarieswa.com/2007/Fi  Red: No Blue: Yes If you spot any mistakes, let me know! :) I've been reading Alain de Botton's 'The Architecture of Happiness' recently. A particular passage in part II of the book seems to do to design & architectural beauty what Pirsig's 'Zen and the Art of Motorcycle Maintenance' did to quality - that is, defining such ethereal idealistic concepts vis-a-vis man: In essence, what works of design and architecture talk to us about is the kind of life that would most appropriately unfold within and around them. They tell us of certain moods that they seek to encourage and sustain in their inhabitants. While keeping us warm and helping us in mechanical ways, they simultaneously hold out an invitation for us to be specific sorts of people. They speak of visions of happiness. -- Alain de Botton, 'The Architecture of Happiness' I have lately been embroiled in a debate about the importance of commenting in code. While I don’t yet believe that comments are completely unnecessary, I tend to think that they are largely unnecessary. Almost two years ago, I wrote ‘Software development without maps’ in which I extolled the virtues of ‘documentation’. While it can be easy to confuse ‘documentation’ with ‘commenting’ and jump to the conclusion that I’m now contradicting myself, I’d like to draw the distinction between the two. Commenting is only a specific type of documentation - a kind of documentation that is so narrow in scope that it only applies to code. [Sidenote: In general, commenting will end up covering the 'mechanisms' expressed by code, and very little of the 'policies' and justifications - which would be best covered by higher level documentation anyway.] In essence, I see programming as an activity where one devises and manipulates abstract models. Writing code is merely a process of expression of such models. What I was trying to get at, in my previous blog post, was that the same models can be viewed at different levels of abstraction. The ‘documents’ encompass knowledge about the models at a higher abstraction level than the code. Documents, being UML diagrams, specifications, or other suitable representations. Comments, on the other hand, are at the same level as code. While it may be useful to sketch out a program using comments before the real code is written, I believe that such ‘scaffolding’ should eventually fade away. Like faint construction lines in a technical drawing, such comments are there to provide an initial framework for laying out the real lines and curves. Like faint and rough sketches on canvas, or a block of stone or wood, the comments become unnecessary as the system is painted, or moulded into shape. As a software system takes shape and matures, the most reliable indicator of what it is doing is the code itself, not any superfluous comments. Indeed, there are various dangers associated with using and maintaining comments beyond the initial stages of coding:
Looking at the issue from another perspective, what about the usefulness of comments? The machine does not care about comments in the code. Comments do not affect the compiler. Comments do not affect whatever is going to be interpreting the code, or some processed version of the code. That is, indeed, the point of comments. Comments won’t make programs run faster, or in a more stable manner. Comments won’t eliminate bugs. If guns don’t kill people and people kill people, then comments don’t eliminate bugs - people eliminate bugs. As far as I can tell, the importance of commenting code is 1) seemingly over-emphasised by Computer Science departments, and 2) an unfounded myth perpetuated in programming shops. OK, after a quick trip through IEEEXplore, I found several papers seemingly extolling the virtues of code commenting. However, they all seem to cite the same paper when doing so. A paper written in 1988. A paper about a study based on PL/I and Pascal. Enough said. Clearly, there has been some research done on the topic, but a lot of it seems outdated, especially in the face of more modern concepts such as Object Oriented languages, etc. I shall delve more into this and possibly post a follow-up to this. In any case, even I was to assume that comments are useful and will bring about world peace, I cannot find any qualitative documentation on the subject. It’s all well and good to say things like “Your code should be 20% commented” or “You need to have comments describing each function” or “Comment about why, not necessarily what, the code is doing”, but no one ever seems to have good examples of such. Such vagueness simply serves to exacerbate the problem - anyone can write practically anything they like in comment blocks and get away with it. “Whaddya mean, I wrote comments! See!” A more practical way of posing this question would be: Given that I have a programming task, how do I write good quality comments that will remain useful to future programmers, given what I know about the problem domain, and how I anticipate it to change? Is there an example of this story and how it pans out? Taking a step back, let’s look at the real problem that commenting pretends to solve. As I mentioned earlier, programming involves the manipulation of abstract models and expressing them in code. It therefore follows that one gains more by learning how to more effectively express programming code than by decorating code with comments. Programming code is the ultimate middle ground - it is something understandable both by the programmer and by the machine (at some level). The programmer who can write prose in comments does not hold a candle to the programmer who can get the machine to execute exactly what he wants to get done. There are two main reasons for the existence of comments in code: 1) making up for the lack of higher level documentation, and 2) attempting to mask complexity by ‘explaining it in english’. The first case is symptomatic of a poor development process, where intentions articulated at the business level aren’t properly captured and architected into solutions at various levels of abstraction. In the absence of UML and other such higher level program models, developers are supposed to resort to code comments to explain ‘why’ certain things are being done, even though higher level descriptions would be more accessible to various stakeholders. (This is a variant of the “explain why you’re doing this” style of commenting) Comments used in such a manner simply mask a lack of traceability between what a particular client wants, what possible solutions are presented and approved, and what ends up getting implemented. The valuable historical record of the back-and-forth discussions detailing what happened and when particular decisions were made, is simply lost. Coupled with an environment where developers are added to and removed from a project in a piecemeal fashion, this is simply a recipe for a fragmented disaster, as few of those involved have a complete memory of the sequence of events. On the other hand, masking complexity by ‘explaining in english’ is plainly disproven by decades of development on programming languages. Concepts such as functions, classes, methods, packages and libraries were developed for the specific purpose of managing complexity by breaking down code into smaller, safer, more tractable and more manageable chunks. Those allow for the implementation of layerable and composable solution patterns, as well as enabling reuse - all techniques well known to help improve the long term reliability and maintainability of software systems. If it weren’t for those, we’d still be writing long epics in FORTRAN.. if we could even get that far.. The fact that classes and methods can be given meaningful names dispels a lot of the reason for using inline comments. Got a function doing lots of things? Break it up into smaller functions that have descriptive names. The code is then easier to follow at a higher abstraction level. Want to zoom in on a specific step? Just go into that function. Easy. Up and down the abstraction ladder. Despite the various reasons for writing comments, it all boils down to managing complexity: the complexity of stakeholders’ requirements, the complexity of the solution at hand. What I’ve been trying to say is that all of this relates to the management of the development process. By building maps and models of stakeholders’ requirements, a better understanding of the problem domain can be achieved. The process of building such maps and models also helps in the discovery and resolution of conflicting requirements and essential priorities. From there, developers can devise subsystems that - when coupled together - should aim to meet the set of requirements. Such subsystems can then be defined in terms of their interfaces and interactions with each other - all at a higher abstraction level. From there, the team can then zoom in further into each subsystem and attempt to refine the implementation further. This same process can be repeated down to applications, services, packages, classes and methods. The whole ‘stack’ describes the abstraction ladder in a consistent manner, and moving up and down this stack constitutes the ‘zooming’ action. Explaining the process in such a way presents a simple concept that can be applied by various people involved in the process. Stakeholders talk to architects and account managers to produce documents and customer-facing models, while architects present the same documents and models to developers for further refinement and evaluation. The end product of this process is a whole collection of inter-related artifacts that document the history of the project and its various aspects from different perspectives - all of which is much more useful and accessible then comments buried deep in the code. Another way of looking at the commenting problem is one of situational awareness. Piles of comments (or code, for that matter) are essentially worthless to a programmer until he reads them. (And when he does read them, the code will provide a more accurate picture of what’s happening, rather than the comments) A programmer (A) who writes some code has implicit knowledge of what the code does and why it’s doing what it does. A programmer (B) who simply reads comments written by someone else has explicit knowledge of what the code is doing, but not necessarily any implicit knowledge. A programmer (C) who reads some code written by someone else internalises a more accurate mental model of what the code is doing. Simply put, programmer A devises a mental model and expresses it in code, while programmer C is doing the reverse process by reading the code and building a mental model. While programmer B has some chance of success at building a model, he might end up doing so ‘faster’ than programmer C, but at the expense of an inaccurate - possibly even out of date - model. This whole construction and deconstruction of mental models is exactly why the ‘abstraction ladder’ development process is powerful - it provides models of varying detail at various levels to enable almost anyone to more easily conceptualise any part of the solution and work with it. Earth Hour was on again last night. As I wrote about last year's event, I figured it was time to post again, though this post won't be about me re-iterating my previous points. I've just read an article on NYT titled The Civil Heretic, about Freeman Dyson and his 'controversial' views about climate change. This particular excerpt reminded me about something I wrote nearly two months ago, which I'll post below: The film continued with Gore predicting violent hurricanes, typhoons and tornados. “How in God’s name could that happen here?” Gore said, talking about Hurricane Katrina. “Nature’s been going crazy.” February 9th, 2009: Bangkok is sinking This article made me realise just how much the global warming alarmists sometimes contradict themselves. There is a subset of alarmists who whine about how urgent action is needed to prevent sea levels from rising. The rationale being that rising sea levels would not only cause small islands to disappear or coastlines to shrink, but mostly that some of the world’s largest cities are located on the coast, and would thus ‘sink’ under the rising waters. Yeah, and? If we assume that sea levels have been variable over the centuries (which doesn’t seem unreasonable), how were people previously affected? Is it not reasonable to say that, as sea levels rose, hundreds of years ago, people from coastal cities and other settlements simply moved to higher ground? They didn’t organise global action against climate change or sea level change, simply because they didn’t have the capability to do so. Alarmism was contained to coastal areas that were actually affected by the environmental changes. Humanity wasn’t just drowned out. To say that humans are arrogant, selfish and destructive just because they decide to not subscribe to geo-engineering on a massive scale is simply disingenuous. What of the arrogance of those who wish to preserve monuments of unsustainability (i.e. strips of poorly engineered coastal urban strips) by performing large scale experiments in trying to influence the global climate? Keep it simple - architect a more sustainable future civilisation that can weather extremes rather than playing global climate bingo. -- While natural disasters strike more and more populated areas these days, the media seize the opportunity to dramatise the situation and attempt to link global climate change to ‘more extreme weather’. While that may be true, why doesn’t anyone pick up on the fact that people have been building cities in downright stupid places over the centuries - New Orleans anyone? What has changed is not the climate (which has always been variable), but people’s growing stubbornness in living on their little piece of land, no matter what the environmental cost - until disaster strikes. Nowadays, instead of properly learning from such disasters, it’s more fashionable to call for ludicrous large scale action to be taken to protect everyone’s little piece of coastline from the growing evils of nature. Current mood:  jubilant.
Current mood:  mellow.
Yes, there's actually a film titled 'Paris'. It's yet another one of those 'multi threaded' plot films, a la Syriana or Babel. It starts off rather confusingly - rather than picking a single starting point, and then branching out, it begins by showing glimpses of all the various little subplots first. Predictably, the subtle links between the various microcosms become apparent, later on. The film is very much a romantic snapshot of life in Paris, in particular the life of Pierre, as he tries to deal with the news that he might not have much longer to live, due to a heart condition. From there, the film tries to link in the lives of the cute girl who lives across the road from Pierre, her history professor and his brother, Pierre's sister - Elise - and a bunch of African immigrants with a brother from Cameroon trying to make his way to the very city, a group of produce vendors from the market where Elise often shops for groceries. There appears to be no greater purpose to the story other than "this is Paris", presented in a way reminiscent of how the history professor attempts to characterise Paris' colourful, multifaceted and 'fragmented' history and personality. Indeed, there are points in the film where you feel that the city itself is a character that unwittingly influences the lives of the human characters that live within it, whether it's by drawing them in from far-away places, frustrating them about their various day to day problems, presenting them with awkward romantic opportunities or offering them hope and joy. Current mood:  satisfied.
I didn't turn off any lights during the so-called Earth Hour 2008. There were 3 or 4 lights on at the time, each rated around 15-25W - yes, those hazardous, mercury-vapour-containing compact fluorescent bulbs. My UPS monitor logged approximately 300W usage while I was playing Call of Duty 4 online. (That’s including various network equipment - modem, switch, wifi AP - a low power file server, a 22” LCD monitor and a PC with an Nvidia 7600GT GPU.. plus a macbook charger) I didn’t replace any lights with ‘calming’ oxygen-sucking candlelight, nor did I use any phenol-producing plastic glowsticks. I’m glad that others did, however, turn off their electrical conveniences and replaced them with alternative pollutants, if only for an hour - all in the name of raising global awareness of .. what was it exactly? Energy efficiency? Pollution reduction? The minimisation of resource depletion? Carbon Dioxide emissions reduction? Oh yes, that’s right.. ‘global warming’. And, while they did so, coal-powered baseload power plants kept on belching their millions of tons of Carbon Dioxide, soot and other air pollutants. Here’s an idea for Earth Hour 2009: How about getting the power producers involved? Instead of just switching off your lights, which does nothing to slow the actual power generation process, why not get power companies to also switch off their power plants? Think about it: instead of then having estimated savings of:
you’d be safe in the knowledge that you actually did help STOP Carbon Dioxide (and power) production for a while, and not just flipped a few switches and buried your head in the sand long enough to delude yourself into thinking you actually made a real impact, in terms of resource consumption. But then it’d take a few days for those baseload plants to cycle back up to full production capacity.. that should be fun - let’s call it Earth Week, instead of Earth Hour! Real progress in energy usage and efficiency don’t happen overnight, and they certainly don’t happen with people just ‘thinking about their energy usage for an hour’. Real progress in energy usage happens in the form of:
So pull your head out of the sand and look at the big picture. It’s a big, energy-hungry world out there. The only way we’re going to make it is not by going backwards to the days where electricity production didn’t exist, but forwards, where electricity is produced and used in a more efficient manner. Current mood:  contemplative.
:) I can't cook when there are dirty dishes in the sink. On the one hand, our kitchen is fairly small, so every square centimetre counts. But more importantly, it's about a state of mind. Doing the dishes is a meditative process, where you rarely have to think much about what you're doing - you simply go about the business of doing it. That said, it's not a thoughtless or careless process - you still pay attention to what you're doing, you're just not solving any hard problems. You don't have to think too far ahead - whatever needs to be done is right there in front of you. There's no anxiety about what's going to happen within a few minutes or hours - you just scrub item after item until it's done. Anything else on your mind dissolves away. A pile of dirty dishes is representative of chaos. It's a pile of dishes and spoons and forks and pots and pans, and we don't know where everything is, in what state it is, and how it got there. That's not to say that I can't deal with chaos, or that chaos needs to be overcome.. Indeed, chaos does not need to, or sometimes cannot be, overcome.. Let's take, for example, a memory dump. Dumping memory from a computer results in something that looks rather like random garbage. Here you have a pile of random garbage from memory. It's a chaotic, incomprehensible mess, and there isn't much use for it. But if you knew the about the internal structure of the data therein, you could do something useful with it. If you knew the precise locations of various data structures, you could read or write to them and possibly do some useful work. If you even studied a random dump of memory and came to an understanding of its internal structure, you have not overcome the chaotic nature of the object. Indeed, the object hasn't changed - what's changed is your understanding of it. What used to be a random, messy pile of garbage now has elegant structure; though not because the pile transformed into a beautiful shape, but because the observer's knowledge and perception of it has changed. The inherent complexity is still exactly the same. So in a way, you have overcome chaos, but you haven't. The chaos is still there, but you know how to navigate it. It's like having a messy room but knowing where practically everything is. It's like working on a software project with hardly any documentation but knowing practically which subsystem does what. It's like knowing where every single item is, in the kitchen, and what state it's in. Doing the dishes isn't just a process by which the dishes are cleaned - it's a process whereby I can ascertain the location and state of every utensil that could be used in the cooking process. Current mood:  hungry.Current music: Lacuna Coil - Our Truth. Rescue Dawn's a pretty cool film all round. Christian Bale gives yet another compelling performance as the ever-resourceful Dieter Dengler. Despite the feature length, however, there isn't much depth to the story - what makes the film enjoyable is the way it brings the South East Asia of 1966 to vivid life, and Bale's relentless character. Despite Dengler's seemingly traumatic experience, he seems to push through it all just fine, never losing hope, and ends up back home wanting a steak.. There's no tectonic shift of character deep within, no complex insight earned during the experience. Despite that, you can't help but think that Dengler was some 60's era MacGyver and Michael Scofield all rolled into one.. For an experience of a different kind, though, I finally decided to check out Sin at Gilkinson's Dance Studio. ~22:50: Arrive at Sin. Oh wow, there's a 'Sin' sign glowing red outside. Two girls wearing black look at me from their bench, as I walk past. 'John' at the front desk tells me about Das Bunker and I tell him I was at the studio earlier, asking about it, with no one seeming to have a clue about the event. So anyway, taking a page out of antzpantz's book.. DAS BUNKER, featuring Assemblage 23 happens at Gilkinson's Dance Studio on the 5th of January 2008: Though, unfortunately, I still have no idea where to get tickets from. I'm still waiting for an e-mail reply from the promoter.. :P ~22:55: Inside the club, so dark and smoky. There's a dance floor with maybe one or two dozen people moving about. No serious dancers here.. Practically everyone is wearing black, or some dark-coloured clothing. Fascinating. I find the bar and order a beer - prompt service, slightly cheaper beer - not bad. Beer in hand, I amble over to a corner of the darkened ballroom and sit by a cuboid table glowing red. It's all dark and smoky, with blue lights dancing around, and tables glowing red. There's a black and white clip of what seems to be German WW2 propaganda looping over and over on the projector screen. The music doesn't sound familiar, but it definitely consists of some hard-edged pounding that sounds great. "This is unlike anywhere I've ever been to, in Perth." The club slowly seems to fill and a bunch of guys sit around my glowing red table and do jagerbombs, one of them practically spilling half of his drink on the floor in the process. Prodigy's Breathe comes on and the whole club ends up on the dance floor. Lots of dark-clad bodies frozen in stroboscopic motion. I almost lose my glasses. The only familiar synthpop music I end up hearing is Neuroticfish's 'They're coming to take me away', which surprisingly seems to engage quite a few of the dancers. Further along, the only other familiar beat I hear is a sample similar to the start of Dismantled's 'Anthem' looping over and over. I end up leaving around 01:40, just after a hardcore mix incorporating Rammstein's Du Hast. Current mood:  exhausted.Current music: Dismantled - Get it through. |
|||||||
|
|
|
|||||
