More Cowbell

I've been playing with Scala a bit since my last post, I actually took a little hiatus from Sedition to avoid burnout...

Scala is a very sexy language, it's very hard not to crack a sheepish grin when reading about it's features.

for instance:

class Foo[T <: { def bar(): Int }]

{

}

Scala and Random musings

I've always been a programming language geek. I love learning new programming languages, though C++ and C# (and to a lesser extent Java and Ada) have paid my mortgage over the years.

I'm more of a fan of statically typed languages, but when I have to, I can feel my way around Python. Windows Power Shell is also a fantastic dynamic language that doesn't get the credit it deserves. I'll admit the syntax can take a little getting used to, and if you don't use it frequently, you will forget a lot of it.

For a reason I can't remember now, I recently read about Scala. (Wikipedia) I'd heard its name thrown around for a few years, but never really looked much into it. If a language is not available for production use for me, I have a little less incentive to check it out. Scala's primary platform is the JVM, and it can also run on Android's Dalvik without too much fuss. There is a .Net variant that uses the Java-.Net bridge/abstraction framework IKVM, but it is apparently not quite ready for prime time.

Faster horses couldn't drag me away.

Henry Ford once said: "If I had asked people what they wanted, they would have said faster horses".

The profound truth to this is that 'customers' are often much better at describing their problems than coming up with solutions. Engineers too often are better at coming up with solutions than they are in seeing the true problems. The key to getting things done as an Engineer is to recognize when you are attempting to make a faster horse instead of inventing a car. You have to work with your 'customers' (be they clients, other departments, or even other engineers, consuming your code), to come up with the solution that matches the right problem.


I have thought this for a long time, and I blog about it, but I do it too all the time. It's very easy to fall into a trap, it's often hard to tell when you're building faster horses until your halfway done building them. Customers often give you a solution instead of a problem ( eg: "I need a file browser with twelve bookmark buttons", instead of "I need a faster workflow for frequent opening of files"). It's all to easy to build that fancy file browser, only to find out later the button for launching the browser was nested too deep in the UI, and moving it would have solved 99% of users problems.

--P

Busy bee.

Usually, when I'm not posting, I'm working on things to post about, or Sedition.

I have a new version I'm putting out later today, with a ton of new features and polish.

I need to do some more heavy duty optimization. Some of my recent optimization seem to make the general framerate appear less stable, even though the code is doing less, and the frames are consistently rendering in less time.

I cannot wait to get back to hardware stuff!


--P