Yet Another Cognitive Architecture (or Web Framework)

There's nothing new under the sun.

Back when I followed java.net better, it seemed like several times a week I'd see passing announcements of new Java web frameworks. This list (on java-source.net) shows at least a few of them.

Studying AI and machine learning again, seems like I'm getting some deja vous. Everyone has another algorithm, or even full cognitive architecture (though that term itself is only used in certain circles). Apparently folks noticed this even years ago. I'd like to eat more pudding, personally.

Side note, sort of interesting to see Google suggestions for searches beginning with "yet another".

WebGL (3D graphics) in Firefox and WebKit

This news on WebGL is seriously cool. This O3D vs. WebGL concept is also interesting.

Taming C++

For certain reasons, I've been coding C++ recently. While I'd learned C++ before, this is the most consistently I've dug at it for a while.

Thing is, I don't like the std (STL) way of looking at things. I'm glad that C++ has a more standard library, and Boost tries to fit the same mold, but there's still a large diversity of style vs. the comparative uniformity in Java land or some other languages.

So, I'm going to the pain of adapting C++ to my style, wrapping various external libraries. (Trying to keep dependencies to a minimum, though.) Sort of a domain-specific view of the world, as is so common for C and C++ coding.

End result is that I've figured out how to make non-nullable opaque handle types with optional auto-disposal (simplified beyond auto_ptr) and whatnot. Some simple templates, too, but nothing crazy. Made a type similar to Scala's Option to get nullable when I want it.

I also have the build incrementally making sublibraries to enforce dependency ordering.

And Eclipse CDT is autocompleting and so on across most of the system quite nicely. Debugger's not working in Eclispe, though.

The end result isn't perfect, but it's really not that painful at the moment. Lots of tasks not solved yet, though, like IO, character set conversion, networking, etc.

Particle-Based Physics

I'm interested in rather detailed (and still high-speed) world simulation. I still don't know all what's out there to handle things for me. I have been learning Bullet Physics. What I'll want someday, and what I'm not sure Bullet provides is fluid simulation. I want air and water.

Seems like the most straightforward way to do this is to simulate particles. Reminds me of smoothed particle hydrodynamics models that I worked with a bit at LANL many years ago. Seems like if you represent matter as particles, and those particles have properties to represent how they bond with each other based on proximity and whatnot, then you can get water and air resistance and so on.

If bonds can be more or less rigid, and if you prebond some particles, you can make rigid bodies, too. 8 particles with strong, rigid bonds and zero radius could make a box. 2 particles with positive radii could make a capsule. Strong yet flexible bonds make soft bodies, like what Bullet provides. But if the bonds are still breakable (and don't easily reform), seems like you could simulate awesomeness like breaking objects into pieces or otherwise damaging them.

Sauerbraten's ragdoll physics system seems related, too.

Oh, and of course there's also a relation to finite element analysis.

The question is if you could optimize dynamic resolution and certain common cases such that the generalized system could still run at high speed. Seems like it could be super awesome if so.

Uncharted 2 Cinema Mode

This peek at Uncharted 2 machinima support looks pretty good. Much nicer than Spore GA in many ways, but it doesn't seem to have built-in, high-level scripting support. Probably lower-level mods could cover in some ways.

I still think high-level machinima is much more the future of home animation than traditional tools like, say, Blender. I guess that's part of why the Blender Game Engine seems so important.

Got to make it easy. Simulate and automate. That's more approachable and, in the end (probably sooner than later), likelier to be more realistic than than expecting people to do all that stuff manually.

Unit Tests in the Core Language for Improved Duckiness

I've thought some about how you could make a language that looks ducky (no types required) but still is semi-statically typed for speed, toolability, and so on. One option is the run-time tracing option used by Psyco, TraceMonkey, and so on. That is, see what types are needed as the program runs and JIT specialized code on the fly.

Another alternative, really making things more static is to make unit tests an important part of compiling code. Sort of like how to need to give examples to C++ for template creation. It only knows what typed versions it needs to generate if you try to use those types.

For example:

def factorial(n, one) = {
  var result = one
  while (n > one) {
    result *= n
    n -= one
  }
  result
}

No types to be seen. Expected available operations ('>', '*', '-'), yes. Side note, that need to specify the "one" above is annoying, but I don't want to think of anything more clever at the moment.

Now, in my unit tests, I could say this:

assertThat(1) == factorial(1, 1)
assertThat(24) == factorial(4, 1)
assertThat(6.0) == factorial(3.0, 1.0)

If the main compiler/builder is aware of the unit tests (which I should have anyway, right?), it is aware of which types are available for the function/class/whatever in question. So, 'factorial' clearly needs both integer and floating-point (or whatever) implementations. I'm being vague on the language specifics here. Also, the main code base could also be used for inference. The unit tests just have a chance to go beyond that.

Such a system should even be able to determine which spots are co or contravariant. Not sure how many examples would be needed. I'm not even sure if this a good idea, but it's interesting to think about. Maybe some type placeholders, like templates in C++, would still be helpful.

This technique wouldn't require unit tests to be embedded in the main code. I personally tend to like the current common technique of parallel dirs. Main code here, tests over there.

Oh, and I also like screaming fast compilers. I'm afraid fanciness like this might slow things down just a tad ...