Tuesday, November 11, 2008

Favorite Programming Language Qualities

Here are my favorite qualities of programming languages:
  • Consistent (orthogonal feature set)
  • Expressive
  • Convenient
  • Small (core language features and API)
  • Extensible
  • Safe (encouraging quality code)
  • Familiar (for newcomers)
  • Easy reading for people (for newcomers and experts)
  • Easy reading for computers (toolable, optimizable)

I think some of these tend to work against each other, and some support each other.

Looking at present times, small core APIs (microkernel-ish) sure aren't in vogue. Rather people tend towards "batteries included". Note that a small core should make cross-platform easier to do.

I also wonder if the current trend towards optimizing and tooling dynamic languages will eventually overcome static languages. I think it will be a while yet, but things seem to be moving that direction.

Wednesday, November 5, 2008

TeXlipse - Sweet

Finally remembered to search for "LaTeX Eclipse", and it sure found something. I just got started with TeXlipse (as in, just now), so I might not know all the down sides, but it seems really useful at first glance (autocompletion, highlighting references, BibTex support, ...).

Monday, November 3, 2008

Performance Basics

From my experience, it seems like these are the basics of achieving good performance:

  • Cache.

  • Index.

  • Parallelize.

  • Profile.

  • Simplify/Shrink (without changing external behavior).


If you move to a fuzzier world, these become additional techniques:

  • Approximate.

  • Simplify/Shrink (by changing requirements).


I don't emphasize algorithms, because picking up ready-made algorithms from a third party is so common these days. (Does that mean we actually make progress? I think so.) However, some folks still have to provide said algorithms, so it might apply to you. The same kind of issue applies to being hardware-friendly, I think.

Anything else I'm missing that doesn't fall into these categories?

More Research Bullet Points

Also wanting to track other things on my sometimes-too-subconscious radar, here are additional bullet points to follow up my research mission statement:

  • Good enough now is better than perfect later. Related to performance profiles and satisficing.

  • Multiple strategies at all levels simultaneously, including alternate algorithms. Different kinds of feature spaces in use. Parallel computation to let bests bubble up on different paths. (More on this and the next bullet discussed in my later "prioritized reduction engine" post.)

  • Metathinking. How to decide what to think about. CPU cycles are scarce resources.

  • Software built to be usable by third parties, not just for experiments. Open source where possible.

  • Multiclass assignment ("tagging" in modern netspeak) and fuzzy class membership.

  • Graph structure matching (analogies). Relationship to traditional predicate logic?

  • Ensemble of simple behaviors often better than single complex ones.

  • Allow compromise between behaviors. I might want to rest an injured leg, and I might want to walk somewhere. One doesn't have to rule out the other. I might just walk slowly, more carefully, or less often.

  • Automatic splitting of problem space into different behaviors. (Learning basis functions.)

  • Behavior activation/deactivation based on applicability and thinking resource limitations.

  • Behaviors as semi-peers rather than specific layers. The kinds of controlled actions or perhaps group activation/deactivation might imply layers still.

  • Root behaviors live independently. Some behaviors could spawn others which might be short-lived. Longer-lived behaviors might attach themselves as roots.

  • Hmm. Almost sounds like a hurd of interfaces representing depth of Unix-replacing daemons of interfaces representing depth ... I mean, like a multitasking operating system. No, I've sadly never used GNU Hurd.

  • Simulation is nice, but real world rules.

  • Most things shouldn't require huge hardware. If it doesn't go fast enough, find better algorithms.

  • Be willing to be inspired by biology, but don't get too committed to the idea.

  • Dynamic dimensionality. If sensors or actuators (or intermediate computation results) come or go, the show should go on. Algorithms shouldn't need recoded to deal with extra dimensions.


I've been warned some about watching ideas closer so other people don't steal them and publish first, but I think my chances of being seen by a potential idea thief are low. Until I get super famous (cough, cough) of course. And most people prefer to pursue their own ideas more than those of others.

And finally, I can't do everything anyway. If someone gets cool ideas from me, I guess I'll just have to hope it's something I wouldn't have gotten to.

Finally, this stuff here is still pretty high level. Not exactly a how-to manual. Need to figure out all the how-tos myself first, anyway, if I even get to focus on any of this.

So, um, steal away or something.

Saturday, November 1, 2008

Simple Research Mission Statement

Here's a stab at summarizing a research mission. Focus is hard for me, so this seemed like a good exercise. I'd like to focus on these things:

  • Everyday, general-purpose robots.

  • Real-time, multi-objective, very high (10s, 100s, 1000s?) degree-of-freedom decision making in dynamic environments.

  • Preference to automatic learning over hard-coded engineering. Also, parameter elimination.

  • Extract research from practical application rather than hoping theory will be practical. In other words, how do I know I'm asking the right questions?


Maybe I can refer back to this or post updates (like these bullets) as needed.

Tuesday, October 28, 2008

The Web Client Platform

With Firefox (and presumably others) getting fancy scene graphs with video on all three platforms out today (in beta form), and with JavaScript JIT support coming in the near future to multiple browsers, where does that leave client-side Java?

If someone makes serious (and open source) dev tools for JavaScript, I'd probably move on. JS has flaws, but so does Java.

There are nicer languages out there than either one, but I always feel drawn back to the main language for the platform. But that's also part of why I'd rather see good JS tools than use GWT. I just haven't seen them yet. Still, JS is the metal in browsers.

I'd also be curious to see a server-side JS framework get traction. Hasn't happened yet despite many attempts. Nothing is yet (and perhaps never will be) "the metal" on the server.

Monday, October 27, 2008

JBullet in jME Physics

Just noticed today that JBullet support is in svn for jME (jMonkeyEngine) Physics. I tried out the ragdoll demo, and it seems like things aren't quite ready yet. But still cool to see the development.