What's it all about, Alfie?

A good friend of mine tweeted this post from Joe Armstrong, the designer of erlang, about what it takes to get started with a new language. It's most interesting to me that I agreed with everything in the post before I even knew who had written it. What makes it so wonderful to me is that it is so incredibly spot-on is... well... everything!

He tells the starting developer to type in a simple little Hello World program and then run it.

Thats all it takes - typing three lines of code into a file with a text editor - then typing two lines into the shell.

That's all it takes. 95% of all the fun can be achieved with a simple text editor and the erlang shell. That's how most of the erlang system was implemented.

Which I get as that's the way I've evolved my erlang programming. But he goes on to say:

Me I use
     - a shell
     - makefiles
     - emacs
for all know programming languages under the sun.

98% of all the fun can be had with the compiler alone - all the rest is hype.

But the real gem is just after that:

After 30 years you will get the hang of this and be a good programmer.

and that's the thing I think most people are missing these days - things take time, and there's no guarantee that after that long you'll be some expert, but there's no way to become an expert without putting in the time.

He's right:

IDEs and build tools are the single biggest obstacle I know of to getting started.

I'd just add "...and becoming good." You can't let some tool do things for you that you don't understand. If you understand how to do it, then it's OK to have a tool that helps you, but you have to have the eye to be able to detect when the tool has gone wrong, and be able to correct it easily.

I'll never forget in high school when my Trigonometry teacher insisted we learn the half-angle, and double-angle formulas for trig functions, and then the 30-60-90 and 45-45-90 triangles. I thought What a waste - we'll always have calculators!

Fast forward to my junior year in college on a test in Mechanical Engineering. I'm doing the trig functions on my aging calculator and the numbers just didn't look right. Sure enough, the cos() function wasn't returning correct values. How did I know? You betcha, those triangles and formulas that I knew I'd never need. Yeah... right.

With those same formulas, I was able to convert them into sin() functions and finish the test, but had I blindly followed the calculator, I'd have messed up the test something horribly. Same with IDEs - nice, if you know how to do it already, but they really do get in the way of learning the language. The syntax is important. You can't short-cut the learning of how to code in a language, you just have to do it.

Maybe I'm old school as well, but I'd much rather be in this boat than the Learn Anything in 21 Days crowd.

This morning I noticed that Google Chrome dev 14.0.814.0 was out, and while it's been a while since they've released an update, it's nice to see that things are stabilizing out and settling down. Seems like the biggie in this release is the V8 engine to 3.4.7.0, which is nice because that's becoming the new development/deployment environment. While you're not going to do a lot of high-powered math, I have read about someone's extensions to WebKit to include OpenCL and the GPU processing for JavaScript. Now that would be neat. To be able to use the GPU in JavaScript without having to explicitly code for it. That would be neat.

In any case, it's up, I got it, and things are going well.

Today I was able to really get some good data for the comparison of my Greek Engine and the legacy tools and things are really lining up. The problems that remain are really in the area of how to handle pre-open quotes and trades, and how to handle the close. I've been through this all before, and I knew it'd be tricky. It's not horrible, it's just methodical. You have to look what the legacy code is doing, and then try to emulate that in your code with some eye towards the future. Just takes time.

At the same time, I found a few really amazing bugs in the code. Things I should have seen a lot earlier, but were looking right over far too many times. One is the extraction of the symbol name from the SecurityID - a 128-bit number that packs a lot of information about the instrument in those 128 bits. An uninitialized SecurityID will appear to be a stock with a symbol name of no length. I was treating that as an error rather than dealing with it and returning an 'empty' name.

But even more amazing is that the error I was trying to log had a hex dump method that didn't support empty data sets. This, coupled with the fact that I was trying to convert the SecurityID to a (uint8_t *) and the compiler was turning it into a std::string, with zero length, and it was just a mess. I had to fix the hex dump code, the symbol extraction, and things started acting much better.

Days like this are really pretty nice. I get a lot of things done, they all impact the bottom line of user experience, and it's nice to get a lot of "things" done. Good day.

Today I started the somewhat painful task of matching numbers in my Greek Engine to those of the existing system. The reason this is so hard is that you need to get the same inputs at the same time and then you're able to see if things line up. In order to know all the inputs, I needed to spend some time cleaning up a little code and extending the IRC responses so I could see all the values for each instrument.

There were a bunch of nagging bugs as well - nothing show-stopping, but a lot of issues with the user experience if they put in bad data in the IRC client. While it's bad data, the code shouldn't have responded the way it did (core dump), so I had to track those guys down and fix them as well. Nothing horrible, but it's the immediacy of the work that's the pain - there's some tester waiting and I needed to stop the other work I was doing to get these fixes in.

Nothing horrible, and I'm starting to see the fruits of the labor, but there are other issues about the timing of the close, and how I handle the last ticks of the day. I'll have to give it more attention on Monday.

After another recent beta release, iTerm2 1.0.0 is out. This is a really nice replacement for the Mac OS X Terminal.app and has a lot of features that I don't even use. It's the BBEdit of terminal apps. It's got more features than I think almost anyone would need. One of the ones I really like is the ability to hide the scroll bars. I just don't need them, and they don't make it easier to scroll - that's built-in to the OS. Maybe with Lion (10.7), they will be less intrusive, but for now, I really like iTerm2.

This afternoon I've been adding code to my Greek Engine to enable it to automatically add instruments from the exchange feeds based on some simple rules. The problem is that many times, the first time we'll get word of a new option will be in the ticker feed from the exchange. They happen intra-day, and it's something we have to be able to respond to no what the conditions. There will be both stocks and options being added intraday, so I needed to be able to add either - but the trick with the options is that I need to know who to place this option on.

This means I needed to expand the list of all the stocks I know about, and when I get a new one, I'll add it to this list as well. Then, a new option can see if it's underlying is defined, and if so, add itself appropriately. If not, then it falls on the floor simply because we don't have enough information to place it in the structure. So it goes.

These changes didn't really take all that long, which was nice, but I'm guessing there might be some things I have to polish about this before it hits production... after all, the legacy code it's replacing didn't handle stock additions at all.

This morning I've been finishing up on the conversion of the code from the string-based security keys to the 128-bit integer security IDs, and it's really taking shape nicely. The

messages weren't as bad as I feared, and the Greek Engine had both in the instruments, so it was just a matter of serializing/deserializing the 128-bit integer version in place of the string one. Not bad at all.

The tests look good, and with this, we should be ready to handle much improved client support and speed. Not bad.

It's quite possible that the problems I've been having with FreeTDS and iODBC on Ubuntu 10.04 are solved. One of the other guys working on this problem with me spent a little time this morning looking into this issue and seems to have found it to be a pthreads deadlock. By simply changing the threading model used by the ODBC driver, things seem to have stabilized. This is done by editing the /etc/odbcinst.ini file to include the line:

  Threading = 2

When I added this to the configuration, all the lock-up connection problems I've been having went away. It appears to be that the FreeTDS driver isn't thread-safe on the connection level, so this make sure that only one thread at the ODBC level uses a particular FreeTDS connection object at a time.

Fantastic news!

Wow! I checked this morning and WordPress 3.2 is out, so I ran over to HostMonster (again), and upgraded all my installations right away. It's fast and painless, and the new features - like the reworked dashboard and the new "out of my face" editing page are all steps in the right direction, in my book. Very nicely done, indeed.

Much of this afternoon has been spent updating all the messages and methods to stop using the string-based security keys and start using the 128-bit numeric security IDs. The reasons for this are many, but the most obvious ones are the size of the information, and the speed with with which it can be processed. We are getting into the time when we're looking at multiple kinds of clients, and in that we need to be able to do things very fast. Like crazy fast.

The parsing of the components in a string are OK for random use, but when a client needs to parse the strike (for instance), it's far faster to have it be an integer - even a varint, than an ASCII string that has to be walked and built up.

Unfortunately, this code touches nearly everything. So it's going to take a bit of time to take out the strings and replace them with the 128-bit integers. But we'll get there, and when we do, it'll be a better solution.