Concurrency Bragging Rights

Wes Moise writes about upcoming advances in concurrency in C# and Java. He sees C# as making the bigger leap into the state of the art.

It’s safe to say that Microsoft will be addressing this issue soon, and probably will be leading the way. As for Sun, Java 5 introduces some concurrency features such as AtomicInteger types, ReentrantLocks, lock-free data structures, but it’s not fundamentally different from concepts that originated in the 60s.

The smart minds at Microsoft Research have been focused on a new concurrency constructs in COmega based on join calculus.

On the other hand many years ago I was using Doug Lea's wonderful util.concurrent package. This has become "standard" now as java.util.concurrent.

The real problem is C# and Java are still languages from the middle of the pack of "the 60s" languages (e.g. Concurrent Pascal). Languages from the best of "the 60s" like Lisp and Smalltalk, have not had to change much and are able to move into new concurrency models with much less baggage.

I am not sure I would hold either C# or Java on a pedestal for the coming paradigm of concurrent programming. Eeek. Termites!

Middling Around the Real Problem

Update: See the comments.

The paper by Meijer and Drayton is making the rounds. As long as Microsoft supports the popular "dynamic" languages I don't care much what other languages they support.

Since the paper is a work in progress and they admit to being provocative, I may as well comment...

First of all I would note that the term "test" does not show up anywhere in the paper. This is a bit of a shock for a paper whose opening sentence is...

Advocates of static typing argue that the advantages of static typing include earlier detection of programming mistakes.

Moving on to a few unsubstantiated claims...

data intensive applications need to deal seamlessly with several degrees of typedness

I did not see a definition of "data intensive" nor did I see evidence of what this "need" is.

not inferring the types of these variables whenever possible is literally throwing the baby with the bath water

Everything has a cost/benefit ratio, which informs the answer to "whenever possible". I could not find a description of this ratio in spite of that being the topic of the paper.

in general programmers want to express more advanced contracts about their code

Yes, but the question is how, and at what cost. Testing, even model checking, could be brought into this discussion. The benefits of the specific proposals in the paper are not clearly proposed.

The compiler should verify as much of a contract... as it can

More of the same... "as much as possible", "as much as it can"... the problem is the paper should propose some eveluationc criteria otherwise it is your word against mine. I will go with my word every time in that case.

Perhaps the most useful example [of coercive typing] is "auto-boxing" from value types to reference types

If that's the best example then... ahem. One could simply choose a language that does not even have such things that contribute nothing to the real problem.

the compiler can automatically "lift" addition on normal integers to addition on nullable integers

One could simply choose a language that does not even have such things that contribute nothing to the real problem.

[generics make it] possible to create highly reusable languages, while maintaining the benefits of compile-time type checking

Those benefits have a cost. The point is people disagree on the accounting of the cost/benifit ratios. The paper does not propose an accounting that can be examined.

I want lazy evaluation... the power of the Unix shell lies in the fact that programs consume and produce lazy streams

Agreed. But this has nothing to do with type checking. Maybe this would make a better paper than one on type checking for many readers.

Overall the paper has some ideas on how typical type checkers for C# and Java can be improved. That these checking approaches would be better than "dynamic" languages seems to be an assumption the authors chose not to question. Too bad, I thought that was the point. I don't see many people arguing to stick with the poor checking done currently by C# and Java.

T Revival

I am not sure how much this matters today, but the T Project from Yale is being revived. T is a dialect of Scheme whose optimizing compiler was a fascinating piece of work 10 years ago and influenced subsequent work on compilation via continuations.

Jonathan Rees has more interesting T background from the insider's view.

T ran on Apollo workstations among other systems. I used them at Mentor Graphics until Gambit Scheme came along.

Emacs: The Extensible, Customizable Display Editor

I had used Emacs for a couple of years or so when I came across this paper in a book on programming environments. This inspired a lot of my subsequent software design in several domains far from text editing.

Another Radically Tailorable Resource

Avi adopted the phrase "radically tailorable". Great. I like that phrase quite a bit.

Here's another reference that has influenced my thinking long before this post. This should also be in the Lieberary, but some links seem broken.

This paper presents a kit called EZWin, which provides many services common to implementing a wide variety of interfaces, described as generalized editors for sets of graphical objects. An individual application is programmed simply by creating objects to represent the interface itself, each kind of graphical object, and each command. A unique interaction style is established which is insensitive to whether commands are chosen before or after their arguments.

The system anticipates the types of arguments needed by commands, preventing selection mistakes which are a common source of frustrating errors. Displayed objects are made "mouse-sensitive" only if selection of the object is appropriate in the current context. The implementation of a graphical interface for a computer network simulation is described to illustrate how EZWin works.