All in

So, after reviewing the syllabus and text for the Programming Languages course, I decided that I really should take a second class this semester. So I signed up for Advanced Data Structures and Algorithms. That makes it four nights a week and probably 15-20 hours outside of class, but I'm pretty optimistic. These are core courses, so my 30 years of practical experience counts for a lot.

Pseudo answers

This morning I went through all the questions at the end of the first chapter of Sebesta and answered them in my head. Yes, actually writing down the answers would have been better, but I wanted to get through them all and only had about an hour to spend on it. I was a little surprised at how often I flipped back through the chapter to find a supporting fact or clarify an answer. I guess I need to be a bit less arrogant about how well I know this material. Sure, I'm familiar with it, but I don't KNOW it. The former needs to become the latter.

Courses start

Courses started today, but my class this semester is Tues/Thurs. I did read the first chapter of the book (Sebesta, Concepts of Programming Languages). Most of it was material known to me, but I didn't mind going through it. I did catch what I believe is a pretty big omission: no discussion of data-driven programming languages.

This isn't a surprising bias in academia; data-driven languages are generally all vendor 1-off's to support ERP systems. That said, the people who know them are the highest paid folks in the industry, so it seems that one might want to come to terms with them for that reason alone.

The major difference between them and imperative languages is the way variables are handled. Most imperative languages scope variables as local and global. Object oriented languages have more scope options, since things can be visible to a method, a class, a derived class, or everybody. Data-driven languages treat variables as fields in records. As such, the scoping really comes down to who can access the record, not where it's declared or how it gets referenced. Persistence of variables is also very different. Again, it's tied to the underlying record (which may get modified, duplicated, or deleted by any number of processes at pretty much any time) rather than the code constructs.

I'll concede that, in practice, most data-driven code looks a lot like imperative code. But, where it is different, it's REALLY different. Given that the bulk of business programming is moving to ERP systems, an extra chapter on that would have been in order.

Researching bugs

Blah. I hate researching bugs. Microsoft SSAS (their BI reporting solution that sits on top of SQL Server) has more than it's share of interesting quirks. Most of them have well-publicized workarounds. We hit one this week that doesn't. Basically, we need ordered sets coming in on a select distinct. Oracle (which we use as our underlying data store) used to always order select distincts. But then they started ordering the results by the hash code rather than the actual data element. No problem, there was a hint you could use to get around that. Then, with Oracle 11, that hint stopped working. Not sure how we're going to get around this, but it's brushing up my research skills trolling the web for answers.

Two weeks out

Well, things got very busy at work (as they always do over the summer since our big deployment for the year is always in August). I have actually got a lot done on the grad school front; I just haven't been very good about recording it. With classes starting in two weeks, I'm going to try to be better about that.

Sizing the task

I didn't expect any of this Grad School business to be easy, but I didn't expect the shift to regular study to be quite so problematic. I'm glad I'm working through this now rather than when I'm already in classes.

It's not that I haven't taught myself things in the last 25 years. Most of it has been very ad hoc; looking up specific things as I need them. But, some has been more comprehensive. I've read books, learned new programming languages and systems. But, it's always been on an "as convenient" basis rather than rigorous, date-driven work.

Part of the answer is simply bumping this stuff up closer to the top of the list. Because I'm not in class yet, I've been pretty quick to put down the study when it conflicts with something else I care about. It's time to change that so that by fall it's a habit.

First Official Act

So, as my act as an UMSL student, I ran the Mirth Week 5K (not quite sure what Mirth Week is, but it seems to be some sort of Spring Fling for UMSL). Anyway, as most of the field was students and there's not much upside to being old at this distance, I was never in contention for the win. Did manage a decent time (18:28) and fourth overall, so it was a good outing. To get the free student entry, you had to indicate what student organization you were representing. I selected the math club, because I was pretty sure there weren't any math club members in attendance to call me on it.