Blog

• Dealer

  A group of undergraduates from Rose-Hulman Ventures gave Dealer last week on their project working with our ORCA® robot.  We love to see cool stuff in undergrad projects!

  Dealer is our weekly technical seminar that is run by the R&D Software group in Indianapolis.  It's about an hour every Thursday, and we've been running it for almost seven years now.  Talks cover everything from current project work to tools to tech to side-projects at home.  It's informal.  A lot of people use a Powerpoint presentation, but we also see whiteboard work, handouts, and sometimes live code hacking.  Some example topics include

  • An Introduction to (Computational) Neuroscience and Brain-Machine Interfaces
  • Mapping Objects to Relational Databases
  • Splitting Volumes Exactly using Floating-Point Arithmetic
  • Manipulating and Visualizing Multidimenstional Data
  • A Prototype SILAS module in Erlang
  • History of Genetics / Tuberculoses - A New Target, a New Drug
  • Scheme Automated Testing
  • Custom Control Design in .NET
  • Dr. Love and the 10-Customer Visit Marathon

  Choosing who gives Dealer is a little unusual.  Every week someone can volunteer.  If there is no volunteer, somebody is chosen at random, and the odds of being chosen are proportional to how long it's been since you last gave Dealer.  I'll admit lately the practice has been for the Dealer Czar to approach the people with the highest probability and get some consensus on who will present.  Regardless, the system encourages giving Dealer when the time is convenient for you, and it works.

  By the way, we borrowed the name and the system from Xerox PARC, which ran a similar program in the early nineties when I worked there as a research assistant.

  March 16th, 2008
• Objects Have Not Failed

  I really liked Guy Steele's opening remarks at OOPSLA'92. It's a good reminder why object-oriented programming has gotten and kept so much traction for the last fifteen years. When you read his notes, remember that he is using procedural programming with C as his baseline. When he says object-oriented programming is good, I think he is saying these three things are good.

  • Encapsulation and polymorphism. Objects let you encapsulate data. Virtual methods give you polymorphism. Over C, these are huge levers for structuring and reasoning about code.
  • A sound type system. Java and C# provide a static type system in addition, but I think the real benefit over C is simply having a type system that doesn't allow illegal casting.
  • Garbage collection. It's a lot to ask programmers to heap-allocate objects without providing automatic memory management. The nice side-effect is that all dynamic memory management gets handled by the collector.

  Note that by Steele's reckoning, C++ doesn't count as an object-oriented language. C++ is a huge improvement over C, because it provides encapsulation and polymorphism, but it doesn't fix the type system, and there is no garbage collector.

  It's worth observing that functional languages have had all three of these features long before Java hit the scene. LISP had closures, a sound type system, and garbage collection. I think it was Scheme that first introduced lexically-scoped closures, a concept eventually picked up in Common LISP and of course used in all other modern functional languages.

  The differences between popular object-oriented languages and functional languages are technically small but profoundly affect day-to-day work. Functional languages provide lambda expressions. Lambda is a primitive that in the right hands can be used to mold just about any scoping mechanism you need. Class-based object-oriented languages are more restrictive, but that lack of choice makes it easier for programmers to decide how to structure their code. There are classes. Define them. Move on.

  As for type systems, Haskell probably represents the state-of-the-art in type inference and expressive power in typed languages. Unfortunately, the type system is pretty complex, and type errors can be hard to debug. Java's and C#'s type systems are simpler, less expressive, and require a lot more code to be written. In exchange, they are easier for programmers to understand and use. As for dynamically-typed languages like Scheme and Javascript, it allows for more malleable code in exchange for moving type errors to runtime.

  The restrictions on scoping feel confining to functional programmers, but the community at large has pretty much spoken: for the average programmer it's worth the tradeoff. I think the conclusion is much less certain for static type systems versus dynamic type systems.  A recent Yegge rant is in large part fueled by Java's static type system. In the last couple of years there has been a surge in dynamically-typed languages such as Python, Ruby, and Javascript. I think that surge speaks volumes: sound type systems have proven their worth but static typing on top of that may not have legs.

  March 10th, 2008
• UsWare vs. ThemWare

  Jeff Atwood wrote about MeWare, ThemWare, and UsWare.  It draws a useful distinction between the software a lot of us developers use and the software we build for our customers.  Our customer are scientists and lab techs.  They don't spend a lot of time on the 'Net, and for most of them, what they know of social networks comes from their kids. They walk in different circles.

  Our customers humble us, because they want to know as little as possible about our software. To them, software is a tool to get their work done, and the best possible tool is one that is invisible in their mind. Success is simplifying their job  and fading into the woodwork (or lab bench as it were).

  It's a different software design challenge. How do you make software that is invisible?  We visit customers where they work, watch them work, talk to them, and try to get in their heads. We try to make our software map their mental model of the universe and not force them to adapt to us. We think a lot about making features discoverable. We try to avoid surprises. That's tough when you're also trying to solve hard problems for the user, and finding the right balance is tough work.

  That alone makes UsWare fun, but the bonus is that our customers are great people too. They are professionals, they are analytical, and they treat us as partners in improving healthcare. It's a pleasure build software with them.

  March 10th, 2008