Articles
Languages, Levels, Libraries, and Longevity
New programming languages are born every day. Why do some succeed and some fail? In 50 years, we've already seen numerous programming systems come and (mostly) go, although some have remained a long time and will probably do so for: decades? centuries? millennia? The questions about language designs, levels of abstraction, libraries, and resulting longevity are numerous. Why do new languages arise? Why is it sometimes easier to write new software than to adapt old software that works? How many different levels of languages make sense? Why do some languages last in the face of "better" ones?
Fuzzy Boundaries: Objects, Components, and Web Services
It's easy to transform objects into components and Web services, but how do we know which is right for the job?
Extensible Programming for the 21st Century
Is an open, more flexible programming environment just around the corner?
How Not to Write Fortran in Any Language
There are characteristics of good coding that transcend all programming languages.
Self-Healing in Modern Operating Systems
A few early steps show there's a long (and bumpy) road ahead.
Interviews
A Conversation with Alan Kay
Big talk with the creator of smalltalk - and much more. When you want to gain a historical perspective on personal computing and programming languages, why not turn to one of the industry's preeminent pioneers? That would be Alan Kay, winner of last year's Turing Award for leading the team that invented Smalltalk, as well as for his fundamental contributions to personal computing.
Curmudgeon
Linguae Francae
Is programming language a misnomer? Many linguists are still busy trying to reconstruct the single ur-language presumed to have evolved over untold millennia into the thousands of human tongues - alive and dead, spoken and written - that have since been catalogued and analyzed. The amazing variety and complexity of known languages and dialects seems, at first parse, to gainsay such a singular seed.
Kode Vicious
Kode Vicious: The Return
Dear KV, Whenever my team reviews my code, they always complain that I don't check for return values from system calls. I can see having to check a regular function call, because I don't trust my co-workers, but system calls are written by people who know what they're doing--and, besides, if a system call fails, there isn't much I can do to recover. Why bother?
