How to Report Bugs Effectively ("it doesn't work" is not a useful bug report)
Maker's Schedule, Manager's Schedule. An interesting piece that tries to explain why I'm more productive on weekends or at night. Also, for managers, let me work! Meetings that are there for the manager to figure out how things are going are not going to improve how things are going. I know the plan. If things don't go according to the plan, I'll let you know.
Yun-Qi Kingdom. Your assumptions about PHYSICS are totally
wrong! There is NO relativity! You must be punished!Java CoG Kit. It started as a pure Java client suite for Globus. It evolved to a generic API for the things that Globus does (submitting jobs, accessing remote filesystems, etc.) as well as a number of useful software built on top of that. Oddly, it didn't get as much use as I would have expected. People seem to prefer to write custom code to interact with each version of Globus.
Graph Editor (well, more of a viewer, but there is some basic editing). It started out as an experiment to see if (inter)active Java Swing objects can be used effectively as nodes in a graph to various ends. It ended up as an exploration of dealing with large (100k nodes) graphs while keeping interactivity. To that end it contains a layout algorithm based on GCD (clan decomposition), but faster. That is achieved by strategically removing edges from the graph for the purpose of computing the layout. Hasn't been maintained in a long while.
Karajan (a parallel scripting language). There are a number of ideas that went behind Karajan:
We avoid using threads when we write scalable software, and use things like select() instead, things which are difficult to reason about. We do this not because the concept of threads is fundamentally unscalable, but because threads (or at least preemptive threads as currently implemented in most OSes) are heavy resource consumers. We could use cooperative threads, but that can also go wrong because of those pesky threads that fail to cooperate.
There is, of course, no clear solution. Each comes with its trade-offs. However, one step forward would be to explore what happens if one doesn't have the above constraints. What if one were to have a language where threads were sufficiently lightweight and seamlessly integrated such that one wouldn't have to think about them as some entity to be avoided unless they are really needed? In other words, what if we were to treat threads simply as a way of expressing concurrency/parallelism and not have to worry about their implementation?
Purely functional languages are consistent without needing to impose strict temporal restrictions on the evaluation of functions. That's what allows implementations of purely functional languages to use lazy evaluation. But lazy evaluation is notoriously difficult to debug, precisely because the order of evaluation for anything but trivial programs is largely disconnected from the structure of the program. If one were to write an eagerly evaluated equivalent of a functional program that would behave similarly to its lazily evaluated version, there would be many GOTOs in the strangest of places.
So one idea is to add parallel and concurrent operators that do not have a functional impact on the program, allow efficient execution, and preserve locality with respect to concurrency. For example:
s1 := sum(a(), b()) s2 := sum(parallel(a(), b()))In calculating s2, a() and b() are run in parallel, but the result is the same; parallel() is, functionally, the identity function.
LISP introduced the concept of "program as data". However this mostly applies to places where there is a fixed number of data items. There is no natural way of dealing with variable numbers of items, except for wrapping them in a list, which may then require side-effects (append operations) for efficient manipulation.
That doesn't need to be so. The ideas of list comprehensions can be naturally integrated into a language using varargs and multiple return values. There is no reason to not be able to say "I want a list made of 4, 1, 0, and then all integers from 10 to 20 which are divisible by 3":
list(4, 1, 0, for(i, range(10, 20), if (i % 3 == 0, i)))
Swift. I wrote the prototype of Swift in one month with Yong Zhao (he is now at Microsoft Research). He wrote the translator and some of the data/type libraries, and I wrote the runtime and some of the data/type libraries. Parts of the runtime are written in Karajan.
Swift is an attempt at enabling large scale execution of coarse-grained applications on distributed resources (such as OSG and TeraGrid). To some it sounded somewhat simple. The user expresses the dependencies in the language, and the interpreter runs jobs as the data they depend on becomes available.
Simple, except services fail, and they don't always tell you why. And then you need to find out what the problems with the middleware is, figure what to do in order to avoid or minimize triggering those problems (even that sounds much easier than it is; a few times our only choice was to bypass said middleware by writing our own), and find out what to do in those remaining cases when things fail just because they can. Even worse, sometimes things don't fail, they simply fail to complete. And then you need to figure out what is it that distinguishes something that's taking very long from something that has stopped working.
I2U2.