Denotational Semantics
A friend of mine showed me some examples of the qualifying exams he'll have to take to get accepted into his Ph.D. program, and the Programming Language exams all asked the examinee to give the denotational semantics of a simple language for which the syntax was given.
Although I'm somewhat familiar with what it means to talk about semantics (as opposed to syntax and pragmatics), I'd definitely like to have a better understanding of how one actually gives a formal semantics of a language.
To this end, I did a little bit of searching, and found an out-of-print textbook entitled Denotational Semantics: A Methodology For Language Development. I've read through the first couple of chapters and the table of contents, and it seems like it's exactly what I was looking for.
So far, the introduction to the concepts has been clear, and the mathematics have been built up without too much prior knowledge expected. Some other CS theory textbooks have lost me in their heavy math from the get-go, so I'm glad my lack of experience with mathematical notation isn't holding me back on this one.
The Problem With Threads
I just read a Technical Report from UC Berkeley's EE/CS department entitled The Problem With Threads, which succinctly and clearly captures the problems with the concurrency mechanisms in our currently popular programming languages. It should be very readable to a lay programmer, since only a small section contains formalisms and most unfamiliar terms are defined in the text or footnotes.
To sum it up, threads (shared-memory concurrency) are an inappropriate method of bringing concurrency to a program because they destroy the inherent determinism of sequential programming languages. The tools we have to help deal with the nondeterminism only chip away at the combinatorial explosion of program interleavings, leaving so much opportunity for error that designing reliable and robust multithreaded software is futile.
The report notes that solutions to the problem that retain as much determinism as possible have existed for years, but have not caught on. The author suggests that instead of creating new programming languages, new coordination languages should be used to coordinate components written in familiar languages.
It's a very thought-provoking paper, and I think the conclusions are right on, as much as I'd like a new language to catch on. Massive concurrency is coming, and our current languages are not equipped to tackle it alone.
Code Synthesis
When searching for information about techniques used to efficiently run dynamic code, I came across a dissertation that lines up well with the things I've been thinking about lately. It covers the design of an operating system called Synthesis, named for its technique of synthesizing optimized kernel code at run time.
In addition to dynamic code optimization, Synthesis uses non-locking optimistic concurrency and dynamic scheduling based on run time analysis to achieve incredible performance; by some measures, it is an order of magnitude faster than the Unix it was compared with, and it achieves the real-time scheduling necessary for multimedia work.
Although it was a very impressive achievement, it has since been nearly forgotten, and has now lost much of its usefulness since it was written in assembler code and the Motorola 68k architecture it targeted has fallen out of favor. The ideas seem applicable to higher-level language, though, especially Lisp-like languages in which code is easily manipulated at run time.
I certainly haven't the time to implement such a thing right now, but it's an intriguing idea. I think I will collect resources that might be useful for it. After all, if I continue my schooling, I'll need a dissertation topic too.
Software and Concurrency
As I was doing research for a paper, I hunted down Herb Sutter's article The Free Lunch Is Over: A Fundamental Turn Towards Concurrency in Software to find some passages that supported my thesis. There was quite a buzz about this article when it appeared in Dr. Dobb's Journal and C/C++ Users Journal earlier this year, as it seemed to capture and clearly explain the feeling so many people had been getting while watching what the CPU manufacturers have been doing lately. Everything's going multi-core, even video game processors.
Following a few links, I found that Sutter has written (with James Larus) another article on the subject, this time with a greater focus on software. It's Software and the Concurrency Revolution at the ACM Queue, and it's a broad look at the deficiencies of current programming languages and practices in the face of concurrency, and what sort of changes need to be made to face the future he sees, in which individual processor cores don't get much faster than they are today.
I'm convinced that Sutter's take on the future is at least mostly right, and these articles ought to be required reading for anyone who wants to take up or continue writing software.
Interactive Fiction as Programming
Here's something novel: Craig Latta has created an interactive programming environment on top of a Smalltalk system based on the paradigm of interactive fiction. It's called Quoth, and he's created a screen-capture video demo of it featuring a simple musical application. He intends to use it for live musical demos; the interactive prose should make the programming possible to follow by a non-technical audience.
This isn't exactly an environment I'd like to use for programming anything substantial, but at the very least it's a very clever hack, and it's fun to see programs so fully anthropomorphised. I can see it being useful for making some rather entertaining presentations.