March 11th, 2010 — 4:30pm
The project I’ve been working on for some time (the last year or so) is starting to acquire a more definite form, and hopefully more information about it will be released in the coming months. Its official name is now Poplar, and the current official overview is available here. Basically it revolves around protocol based component composition for Java.
There is now an opportunity to do a paid internship for 2-6 months at Japan’s National Institute of Informatics in this project. If you are a masters or Ph.D. student who is interested in programming languages and software engineering, and you think the project sounds interesting, please do consider applying. Unfortunately the internship is only open to students of institutions who have signed MOU agreements with NII. The list of such universities, which includes many institutions from around the world, as well as more formal information, is available here. If you know or want to learn Scala, all the better!
Comment » | Uncategorized
March 11th, 2010 — 3:16pm
In research and academia, one of the fundamental activities is the invention and subsequent examination of new concepts. For concepts, we need names.
One way of making a name is stringing words together until the meaning is sufficiently specific. E.g. “morphism averse co-dependent functor substitutions in virtual machine transmigration systems”. Thus the abstruse academic research paper title is born.
Sciences sometimes give new meanings to existing words. This could be called overloading, following the example of object-oriented programming. E.g. a “group” in mathematics is something different from the everyday use of the term. A “buffer” in chemistry is something different from a software or hardware buffer, even though a fragment of similarity is there. And so on. This overloading of words gives newcomers to the field a handle on what is meant, but full understanding is still impossible without understanding the actual definitions being employed.
Sometimes new terms can be created using inventors’ names and everyday words. E.g. a “Lie group” or the “Maxwell equations”, or “Curry-Howard correspondence”. This is potentially useful, but perhaps not something you can do freely with your own research without seeming like you’re trying to inflate your ego excessively. (Even though researchers love inflating their egos, nobody wants to admit it.)
There’s a similar problem in software development. When we invent names of functions, classes and variables, the lack of words becomes very clear. Intuitively, what is an “adapter registry”? An “observer list”? Or an “observer list mediation adapter?” My feeling is that we often end up compounding abstract words because we have no better choice. And here lies a clue to some of the apparent impermeability of difficult source code. We need better ways of making names. We’re inventing ideas faster than our language can stretch.
Comment » | Philosophy, Software development
March 2nd, 2010 — 11:12am
The Gregorian calendar has been in use since 1582. Among its features is a moderately complicated rule for leap years: if n mod 4 is 0, then n is a leap year. However, if n mod 100 is 0, then n is not a leap year, unless n is a multiple of 400.
In addition, we live in a world with timezones and regional differences in when countries go on and off daylight savings time, if they have such a system. As yet another example of Japanese rationality, Japan does not have a DST system.
Implementing date and time computations correctly can be very hard for computer programmers and is invariably a source of many hidden bugs that may take a long time to discover. Yesterday, a large amount of Sony’s Playstation 3 game consoles stopped working normally. This was later fixed. There was speculation the error was due to incorrect leap year handling. It wouldn’t be the first time this occurred if this was indeed the reason.
In a software company where I used to work, there would usually be massive troubles every time some country went on or off daylight savings time, or any other time calculation hit a sensitive spot. I’m fairly sure that the world’s software systems, including government, finance, insurance, health care, suffer untold billions of damage every year due to the complexity of the system. Maybe we should simplify it.
I suggest having “years” with 365 x 4 + 1 = 1461 days instead of the usual year for starters. This would move the leap year problem ahead until year 2100, when the next special rule comes in. By that time, software engineering technology should have improved enough that this should no longer be an issue, I hope. If not, we can invent another system by then. Let’s also scrap all daylight savings time everywhere. It’s easy to do and the savings would be huge.
3 comments » | Software development