« April 2005 | Main | June 2005 »
May 30, 2005
The cast system in C++
A long time ago, when the prevalent language was C, all casts were equal in the eyes of society. Then Stroustrup created C++. As C++ grew, its cast system became explicit and rigid. The cast system in C++ has four casts -- dynamic_cast, static_cast, const_cast and reinterpret_cast. The function of these casts is to convert from type to another. The types involved in a cast are usually pointer types, though this is by no means necessary. Even though the intent of the cast system in C++ was merely to mark the different kinds of type conversion, programmers have accorded the four casts different levels of status and desirability. We will learn about these casts in order of their desirability and the destabilizing effects they have on programs.
The highest cast is the dynamic_cast. When converting a pointer of one type to a pointer of another type, dynamic_cast performs a runtime check to make sure that the cast is safe. If the cast is unsafe, a dynamic_cast results in a null pointer. Other programming languages, such as C# with its as operator, have emulated this cast, evidently as a form of Sanskritization. By performing a runtime check, the dynamic_cast distinguished itself as the safest of all the casts. It is least likely to cause access violations or other forms of unrest in a program and therefore leads to the least violent death for a program.
The next most prestigious cast we will consider is the static_cast. This cast does not believe in incurring performance penalties by performing runtime checks. When static_cast-ing from a Fruit* to an Orange*, the conversion will succeed, but if the pointer was really pointing to an Apple, then invoking the getNumSegments() method on it would cause an access violation. The static_cast is less reflective and more worldly because it takes the type information provided in the static_cast statement as the literal truth, even if it results in a little violence down the road.
The runtime information available to the dynamic_cast combined with the authoritarianism of the static_cast has given the nexus of these two casts enormous influence over the other casts. A variable may be created as a Fruit*, but it has the opportunity to be reborn legitimately through the rituals of the upper casts as a Banana*. This phenomenon of being born again has led to this nexus being called the twice-born casts.
The next cast we will examine is the const_cast. The function of this cast is to cast away the const-ness of a pointer. Const-correctness, when used correctly, is a very important and useful feature in C++. In the illusory universe of the stack, where variables and pointers are constantly in flux, it imbues them with an unchanging beauty for as long as they are in scope. The const_cast is willing to trade away this const-ness in return for the convenience of changing a const variable's value. Unless blessed by the mutable keyword, casting away the const-ness of a value is a serious risk to the correctness of a program, which may result in either violent death or unpredictable behavior.
The cast at the very bottom of the cast system is the reinterpret_cast. Faint-of-heart programmers shrink away in horror from the mere shadow of the reinterpret_cast. The reinterpret_cast does the dirty work of converting between unrelated types. Through the menial hands of the reinterpret_cast, a Fish* may be reinterpreted as a Bicycle*. Most coding guidelines in C++ either prohibit the reinterpret_cast or impose severe restrictions on its life. It should be clear why this is the case. If an object is arbitrarily transformed into another of an unrelated type at random, the natural order inherent in society would be transformed to chaos.
Coming across each of these casts designated explicitly in C++ code is an eyesore to code readers and is a testament to the ugliness of the explicit cast system in C++. It is important to realize that each of these casts has its place in an advanced systems programming language like C++. Any type conversion is necessarily an unnatural act to some degree. Explicitly marking them as such is merely a constant reminder to writers and readers of code alike that objects of all different kinds must live together in harmony.
(If the extended metaphor in the above explanation seems entirely lost on you, you are probably not familiar enough with Indian culture. Feel free to email me or talk to me about it. I hope you will still find the technical content useful, because it is accurate. If you are familiar with Indian culture and know what I am referring to, you should know that I don't believe in it one bit. This is intended as merely an extended inside joke that occurred to me in a moment of inspiration.)
Posted by Vishy at 12:19 PM | Comments (1)
May 26, 2005
Vishy's Indian English Dictionary: funda
funda. /fən·DAH/. The skinny. The inside scoop. The nitty gritty. Probably derived from 'fundamentals', but (over)used for just about anything these days, in a manner roughly analogous to the use of the word 'stuff'. As in, "I can never figure out this dating funda", or "Dude, my Windows fundas are weak. Can you show me how to use some Unix commands at the DOS prompt?"
Americans will probably never hear a call-center worker use funda with them, but after late night shifts, they almost certainly exchange fundas of how to make fun of irate American callers. To experience funda being used in all its staggering senses, one would have to hang out with urban college-going crowds in India. It has the potential to be as versatile a word as f*ck in English. I can't wait for the day when funda will be a verb, an adjective and an interjection too! That will be the real funda!
Posted by Vishy at 09:33 PM | Comments (0)
May 21, 2005
Vishy's Indian English Dictionary: dicky
dicky. /diki/. The back of a car. Known in the U.S. as the trunk, and in the U.K. as the boot.
Western travelers arriving in India may break into laughter when the taxi driver, in an earnest attempt to be friendly, asks, "Sir, you want the big suitcase in the dicky, no?" He's trying to be helpful and not dirty.
Posted by Vishy at 10:25 PM | Comments (0)
May 17, 2005
Useless Factoid of the Day #9: Etymology of Ku Klux Klan
Being as I am into names and all, I was somewhat intrigued by a certain white supremacist organization's choice of name, the Ku Klux Klan.
For having been created in an overwhelmingly English-speaking America, it doesn't sound even remotely like English. I had read in my copy of World Book Encyclopedia nearly 10 years ago that the words Ku Klux Klan resembled the cocking of a gun, an argument I sorely disbelieved even though it came from an apparently authoritative source.
In Levitt&Dubner's Freakonomics, I found an explanation that better suits my tastes. The founders of the KKK chose the Greek word for circle, kuklos, and corrupted it slightly to arrive at kuklux. Then they added a Klan for good measure, because several of their early members were of Irish, Scottish or generally Gaelic descent.
This useless factoid of the day was brought to you by the World's Largest Repository of Useless Knowledge.
Posted by Vishy at 08:07 PM | Comments (0)
May 14, 2005
How amazon.com can write an emergency book essay for you
I spend quite a bit of time at amazon.com browsing through products. I may not buy too many things there because as a New Yorker, my cheapskate instincts are being honed to a fine point. However, in terms of sheer utility, their shopping and product listing interface is second to none. Especially with books, you can learn a lot more about them at amazon.com compared to brick-and-mortar stores, where copies are shrinkwrapped.
Once upon a time, in my younger days, I had to write book reports and other essays loaded with choice bull (in many ways, not much has changed since then). The big problem with writing these pieces was that you had to have read the book. At the very least, you had to have skimmed through the book to get a general idea of the storyline and the key themes expressed in the book. Occasionally, I have been in situations, where it is 2am and I haven't cracked the spine of a book, an essay for which is due at 9am the next morning. This, my friends, is an emergency book essay (EBE) situation.
Amazon.com, in addition to laying claim on the largest selection on earth, can also help you out of an EBE situation. One of amazon.com's recent additions to a book listing is the Statisically Improbable Phrases feature. These phrases are the most distinctive phrases in a book and are available when the full text of a book is searchable. They can be quite good at highlighting some themes in the book. Armed with a list of statistically improbable phrases from the book, the editorial reviews of the book on its product page and a reasonably high BQ (bull quotient), it is possible to write an essay that sounds halfway plausible. If you use the statistically improbable phrases to search within the full text contents of the book, you may even be able to see the contexts in which they appear, and in so doing, convince the reader of the essay that you've actually read the book.
For example, let us look at the product listing for The Da Vinci Code and concoct the beginning to a bull-filled essay for this book, using only its editorial reviews and statistically improbably phrases:
The Da Vinci Code, in addition to being an intelligent and lucid thriller, is a journey through the human condition drawing on a collection of fascinating esoterica from 2,000 years of Western history. The relationship between Robert Langdon and Sophie Neveau is central to the book. Robert Langdon provides Sophie Neveau with information from his rich experience as a professor of symbology at Harvard as she proceeds on a journey to uncover the sacred feminine. The book, in its masterful, page-turner style, speaks of a mystery surrounding a royal bloodline marked by a stone cylinder carried by Langdon in his sweater pocket throughout the book. This hard stone cylinder with lettered dials stands as the complement to the soft, nurturing sacred feminine embodied by Sophie Neveau. Along the way, they encounter agents of the Opus Dei, who deny the sacred feminine and believe that the true path to salvation lies in corporal mortification. They wear sharp cilice belts to remind themselves continuously of this principle. The barbs of the cilice belt worn by the lame saints represent all that tears and disparages the seeded womb representing the sacred feminine.
Okay, I think you must have the general idea by now. If you wanted to get fancy, you could use the "So You'd Like To" and "Listmania" sections to produce impressive sounding cross-book comparisons. The above essay is just an example of the wonderful things you can do with the product pages on amazon.com. I don't claim it represents my real views on The Da Vinci Code, or that it is even an accurate representation of that book. I merely wish to bequeath my blinding insight (*cough*) to generations of bull-filled review writers, so they can get out of EBEs relatively unscathed.
Posted by Vishy at 01:01 PM | Comments (0)
May 12, 2005
Vishy's Indian English Dictionary: parcel
parcel. /PAR·sell/. To specify that an item, usually food, would be taken away from the place of sale, rather than consumed there. As in
"What do you want?"
"Chicken Tikka Masala and Garlic Naan parcel."
In the U.S. this exchange would be something like
"What would you like?"
"One order of Chicken Tikka Masala and a Garlic Naan, to go."
Parcel, in its other sense, referring to a packaged item, also seems to have fallen out of use in the U.S. People generally use 'package'. Parcel, in India, is used for both a mailed package as well as to get food to go (in a package)
Posted by Vishy at 09:36 PM | Comments (1)
May 11, 2005
The influence of organizational structure on software
It isn't a stretch to say that the high-level structure of software is influenced by the structure of the organization that produces it. Most successful software today is organized around several high-level components or modules. Each of these modules display the following characteristics:
1. It has a published, well-defined interface for other modules and processes to access its functionality.
2. It tries to minimize external dependencies so that as an application evolves, changes occur in few sharply defined parts rather than diffusively through the application.
3. It hides internal implementation details so that changes and extensions can occur without breaking code that already depends on it.
When the initial design for an application is created, it makes sense for an independent programming team to take on bringing a module from idea to product. Note that this doesn't always mean there are as many teams as there are modules. All it means is that every module typically has one team working on it and that not every team needs to know the internal details of modules it does not own. Thus, in early stages of the application, the design of the application influences the structure of the teams that build it. As the application evolves, this organizational structure becomes more entrenched and the incentive to reorganize the application development team grows smaller because things are working well presently. The cause-effect relationship begins to change and the structure of the application begins to reflect who talks to whom (more on this below).
The question this essay tries to address is how close this organizationally-influenced module structure comes to the technically optimal structure for an application.
(Before you read any further, I would like to note that the idea of organizational structure influencing application structure is not an original idea from me. I had heard it being mentioned in my software engineering class at MIT, but when I looked for it recently on Google, I was unable to find a good attribution for it. If anybody could point me to a good formal statement of this principle, I'd greatly appreciate it.)
Inherent in a company's organizational structure is the organization of its knowledge and intellectual capital. Despite working within the same company, ostensibly towards the same goals, it is hard to eliminate redundant work entirely and make every team perform tasks that perfectly complement other teams' tasks. Personal and team competitiveness ensure that some amount of work gets duplicated between teams that have similar goals. Furthermore, the same competitive spirit leads teams working on similar projects to be secretive and not share details with each other. Several examples of this occurred when HP merged with Compaq under the watch of Carly Fiorina. According to some accounts, for a while, teams from HP and Compaq that were in the same field competed against each other to ensure their survival.
Let's consider how exactly a company's organization can affect the organization of its software products over the course of time. In companies that have a product-centric organization, such as Microsoft, the structure of their software is related to who talks to whom. We have seen some products that worked well, that were designed for each other, such as Windows 3.1 and MS-DOS 5. Other well-integrated technologies like the Office suite work well together because there were direct lines of communication between those development teams. The depth of communication between the various Office teams led to technologies like Object Linking and Embedding, and indirectly influenced the later development of COM, COM+ and the .NET runtime.
Yet, from the same company, we have seen two data access technologies -- DAO and RDO around the same time. I am not familiar with the intimate details of their programming models, but at first glance, it would seem that there is significant overlap in their functions. (Of course, we are not mentioning ADO here, which was another data access library that came later.) Why should all this redundancy in data access libraries have occurred in the first place? My best guess is that the development teams didn't talk to each other all that much. Even today, when I peruse MSDN Blogs, I see comments from Microsoft developers about how they don't know enough about what other groups are doing in such a large software company. When components from teams who don't communicate are brought together to form an application, the components won't always fit well together. In other words, such an application would not always have a technically optimal design. Once a application is released, opportunities to fix these chinks in the proverbial armor become scarce. Kludges and hacks are introduced that fix the problem while maintaining compatibility with the status quo. The evolution and technical optimality of an application are thus influenced by the communication (or lack thereof) between development teams within a software company -- a factor that is often influenced by contingencies having nothing to do with the technical aspects of an application.
Another factor influencing the evolution of an application is its present state. The way an application currently behaves is surely the most obvious source from which to harvest ideas for what can be added, removed or improved in it. Looking closely at an application and analyzing how closely its behavior approximates its idealized requirements may lead to refactoring and code-level interface enhancements. Adding new features to the application may involve clever reuse of code from other components. All together, these activities may boost the technical optimality of an application's design. There isn't much need to belabor the point that an application's evolution is highly influenced by its present design.
So far, we have concluded that the technical optimality of an application's design is influenced by some combination of its present design and the communications structure of the organization that built it. Let us assume for a moment that there exists a truly ideal technical design for an application. It is worth taking a moment to consider which of the two factors we have considered is more likely to push the application's current design towards this truly ideal design. Development teams not talking to each other may lead to some missed opportunities in improving a design technically. Some ideas may never make through the pipeline. As market dynamics and organizational priorities change, these missed opportunities 'stored' somewhere in the collective brain of a team may fall out of focus and never be realized in future iterations of the application. On the other hand, technical shortcomings in the current design of an application will always be present and are governed by such contingencies to a lesser degree. In other words, the current source code of an application and associated documentation acts as a viable and sufficiently stable medium of communication between developers and among development teams, without its being adversely influenced by communications shenanigans within and among development teams.
The above question becomes relevant in the case of open source software, where there are usually no well-defined product teams. Control is decentralized among multiple developers, who may be spread across multiple timezones. Far from even a semblance of a team working in a development cycle, all the developers have to work off is the current source code snapshot of the application and associated documentation. With such a development model, intellectual capital that isn't written out isn't intellectual capital at all. As a result, hardly anything goes without being written down somewhere, where other developers might read it and act upon it. All communication between developers happens in only two ways: explicitly in the aforementioned rigid, restricted way or implicitly through the current state of the application as expressed by its design and source code. Because there is no intellectual capital lost to organizational communications structure, a decentralized, open source software development model is more likely to result in a technically optimal software design.
Posted by Vishy at 12:44 AM | Comments (0)
May 10, 2005
Grade Inflation at Cornell
I just thought I'd share a hilarious tidbit I came across in The Atlantic Monthly.
Cornell is an Ivy League school. Its charter is to attract passionate and smart young women and men, who like to challenge themselves. It, like any other school, prefers to believe it is succeeding at this task, year after year. So, you would think, if Cornell's toughest courses were advertised as such, more students would rise up to the challenge and take them.
Wrong.
Starting in 1997, Cornell decided to publish the median grade in every offered course at the end of term. The result was that students gravitated to the easier courses (not the harder ones), which led to increased grade inflation.
Is this the Law of Unintended Consequences or simply unbelievable naivete on the part of the Cornell administration?
Posted by Vishy at 11:32 PM | Comments (0)
May 04, 2005
Vishy's Indian English Dictionary: prepone
Never in the long and glorious *cough* history of the good ol' United States of America have its people had to deal to a significant degree with English speakers from an entirely different culture and background than their own. From the seventeenth century until the late twentieth century, foreign English speakers that USians have encountered have been from Canada, the United Kingdom and sometimes Australia. However, with the realities of the global labor market changing, USians regularly encounter competent speakers of English from India, either over the phone or at work. The English spoken by Indians makes quite the impression on an outsider for the raw pulse and vibrance that runs through it. Indians have adopted English in ways that astonish even so-called native speakers. Because of closer contact with Indians, knowledge of the Indian dialect of English may serve USians well. In this series, I'll pick words used by Indians and try to discuss their meanings in different senses.
prepone. PRE·pown. To change the schedule of an event so it occurs before its original schedule. The opposite of postpone. E.g. I have to change my flight tickets to India right away; my brother's wedding just got preponed because of my grandmother's failing health.
Prepone is a creative antonym to postpone. It makes a lot of sense when you think about it and I can only wonder why British or American English haven't adopted it. Oh well, all in good time.
Posted by Vishy at 11:38 PM | Comments (3)