briancarper.net (λ) (Tag: College)

Science in America

Wed, 10 Dec 2008 01:25:51 -0800

In the news there is a recent study of math and science education internationally. A lot of the stories set a "US improves in math!" tone. The most negative tone I've seen is "US science performance plateaus".

How hard is it to say that math and science education in the US sucks? Because it does. See the image at the end of this post for one reason why.

In the meantime here's an anecdote. I went to school in semi-rural western Pennsylvania. My math education was pretty sound. Our high school had agreements with a local college so that I even got to take college-level calc while in high school. I held up well and I was competitive when I ended up in calc 2 in college.

Science was another matter. I consider myself to be not entirely an idiot, but I was given nothing to work with in high school when it came to science. My physics and chemistry classes were disgusting. My best physics class was taught by an evangelical Christian who sneaked God into class sometimes (without my realizing at the time how wrong that was). My other physics class was taught by someone who didn't even know the subject. I took a standardized college-entrance exam in physics and I think I scored in the 20-something'th percentile even among Americans.

Meanwhile in my computer programming class I was working on ancient iMac G3's (the crayon-colored space ship cube kind) which barely ran a C compiler. I think we used either Borland or Code Warrior; I don't remember, and it doesn't matter because it didn't work. We had to resort to using QBasic in a Windows 95 virtual machine on the Mac's.

Our library had Macintosh Classics (the box-shaped ones from the early 1500's, with tiny little built-in monochrome screens). There was one computer in the library with internet access, which ran only DOS and could only access the national weather service and some library catalogs. I used to go edit AUTOEXEC.BAT to do horrible things.

The priority at the school was clearly not science education. It was sports. We dumped huge amounts of money into a new sports stadium. Cheerleading and swimming were the most important things happening. No one gave the slightest crap whether anyone learned science at that school. And I suffered for it.

If I hadn't been motivated to teach myself how to program in my spare time, where would I have ended up? Even more behind in college than I was? Not in college at all?

Is it any wonder that at college, most of my classes were taught by non-Americans, and a very sizable portion of students were non-American? This in a city NOT known for its diverse international population. People flew in from elsewhere, went to school for 4-8 years and left. Down the street at CMU the American-to-non-American ratio was even more extreme.

The anti-intellectual, anti-science attitude of many Americans is what I detest most about this country. Science is the most important thing that human beings do. Science is what enables modern life. People owe science and scientists more than they could ever imagine. And instead people take it entirely for granted, and spit in the face of science at every turn.

Now, here's something to make you puke up your breakfast. Public acceptance of evolution, by country. I won't post much about this subject because it would be mostly profanities.

Work

Thu, 05 Jun 2008 20:32:39 -0700

When I was in college, one of the guys in one of my classes was an older fellow who'd been working in the Real World for a while, and he asked me one day what kind of job I wanted after I graduated. I remember saying "I have no idea. Pretty much anything. If Microsoft drove up to my house with a truck full of money, I'd go work for them."

Looking back now, I was wrong. There really are more important things than money. I couldn't do a job I didn't thoroughly enjoy. Not for long anyways. I don't make as much money doing what I'm doing right now as I could be making elsewhere, but I like it. I like the atmosphere of working in a research setting. I can't imagine working in a corporate setting.

I feel really bad for people who work jobs that they hate. When I got out of college I worked for six months doing tech support over the phone for a residential satellite dish company. If not for the fact that I needed money to survive, I wouldn't have. Near the end I was considering going to live under a bridge somewhere. If faced with the choice, I'd probably rather dig ditches for a living than do that again.

If hell existed, for me hell would consist of being eternally bored. I've had jobs that required no thought, just mindless repetition of tasks that were slightly too complicated to get a computer or machine to do. I can't imagine a worse fate. I can feel my brains start to leak out of my ears after an hour of a boring task.

When you have a job where you have to play with data, as I do at times, it can sometimes start turning into that kind of boredom. But then I start writing programs to do all the mindless repetition for me. Instead of spending lots of time solving little problems and doing little tasks, I solve bigger, harder, much more interesting problems that incidentally solve lots of little problems at the same time.

Computers are useful tools for everyone. But in one sense, a computer is often a waste in the hands of anyone but a programmer. The way most people use computers is like using a powerful microscope as a hammer to pound in a nail. Any time you find yourself copying and pasting a bunch of things over and over for an hour, there's something wrong. Any time a human being is forced to do a linear search through a long list of ANYTHING on a computer screen, someone along the line has failed. There are so many of these little problems in most people's lives that a programmer can solve for people.

Academia

Wed, 03 Oct 2007 13:59:31 -0700

After I graduated college with a computer science degree, I had no idea what I wanted to do with it. I was fortunate enough to get a great job in academia. After almost three years in this line of work, I really can't imagine working for a for-profit company as a programmer. Right now I work in psychological research. I make databases and I program surveys / interviews for data collection and other such fun scripting and data-managing tasks. It may not sound very exciting but it involves a lot more than writing SQL queries. In my last job I wrote a huge Ruby framework to do all kinds of stuff, and I had to support Perl and Python scripts, master a statistics package, make web pages, and as an afterthought write plenty of SQL.

Working in academia is a wonderful experience. The people you get to work with are some of the smartest people in the world. Not necessarily smart in the computer world, but smart in the world of psychology, or law, or sociology, or other things. The people I interact with come from a completely different world than the computer world I live in, and personally I find it very refreshing and challenging to bridge that gap. If learning to communicate technical issues to non-technical people is a skill, there's no better way of learning it.

Another thing I love is that there's no pressure or drive to acquire money. At least not in the sense of "we need money money money, get it at any cost, beat the competition into submission, advertise, produce produce produce" Instead there's a drive to do good science. It's a different kind of pressure which I find much more palatable. Of course running a study does require funding and you usually have to convince someone somewhere to give you some, but as a computer programmer I'm far removed from such concerns and I don't have to worry about them. If the study is valid, and if it produces good data on time, and if I do a good job of helping that happen, things works out.

The work is important, which makes me feel good at the end of the day. I'm not trying to pad some billionaire's bank account, I'm trying to further the knowledge of the human race. At my previous job, a lot of the work I did ended up directly contributing to law and policy decisions. Most studies deal with things no one has ever looked at before. It's a much more fulfilling feeling than slaving away to make other people money.

The atmosphere at my current job and my previous one were very laid-back and casual. You generally work with a small team of people, and people just do whatever needs to be done. I've never had to punch a time card. I don't have to wear a tie. There usually are no deadlines where I need to get some product done by X date. There is no product except knowledge and research papers. I don't have to deal with customers. There are no customers except PhDs waiting to read that papers or work with new data.

In my very limited experience, there is a good demand for computer programmers who are willing and able to support a research study. I was really needed at my last job, and I got multiple very nice offers when I started looking to move to the west coast. If you're good, people will need you. If anyone reading this is an up-and-coming programmer trying to figure out what to do with your degree, give academia and research a thought.

Education

Sat, 07 Jul 2007 21:37:47 -0700

I've been out of college almost exactly four years. Looking back at my Computer Science classes, I think I can see some ways that my education was woefully inadequate. Or at least not what I wish it would have been, knowing what I (hope I) know now.

My classes were in C and C++ for the first year or two. I remember being very turned off of C++ because it didn't have a native "string" type and you always HAD to screw with null-terminated arrays of characters. I never once heard mentioned the STL or the benefits of using it, so far as I remember. Only a couple years after graduating did I learn that using C-style header files and functions in C++ was antiquated; it was tolerated in homework assignments and my professors didn't say much about it. I remember learning about C++ templates, but it was a chapter or two blown through in a week. We never did anything useful with them.

I remember distinctly someone asking a professor "which version" of C++ we were allowed to use on an assignment. He responded "standard". When pressed further, he conceded "whatever Visual C++ can handle". My university was and as far as I know remains a Microsoft sort of place. We all got Visual Studio "for free" (meaning it was included as a fee in our tuition, most probably). Linux wasn't discouraged, but all assignments had to be done in VC++. I wish that would have been different. I wish I'd have used gcc or something once or twice. Most of the professors I liked were crusty old Unix guys who advocated *nix personally if not formally in the curriculum; it's one of the things that got me interested in Linux. I wish I'd picked their brains more.

In my last year or so of classes, the entire university was in the process of phasing out C++ and teaching all the core classes in Java. I was lucky to get a mix of Java and C and C++, if only so I could see the differences between them, and I got enough of a taste of Java to know I don't like it. I had one Perl class (the only one offered, that I'm aware of), but it was half a term and focused on CGI. I had some assembler language classes but they were run on a little toy MIPS emulator in (of course) Windows. How bad must it be for the next generation of coders coming from my old college, who have Java as their primary or perhaps only language?

I remember learning about object oriented programming, but the only thing I actually learned from those courses was terminology: constructor, destructor, inspector, mutator. We learned about inheritance but nothing about how it can be useful. We learned about overloading and overriding operators and methods but never anything about when to do it and when not to. I think the word polymorphism was mentioned and defined, but never explained with good examples. We never touched design patterns; I read a book about those a few months ago and it was a real revelation in many ways.

I learned a lot about binary trees and stacks and priority queues and graph search algorithms. But I never really learned about when we should use those things and when not. I never had an assignment that said "Here's some data; pick the right data structure to model and organize and query the data and write a program that does it". In 90% of my classes I probably never wrote a program longer than 200 lines of code. My courses had me writing and re-writing and re-re-writing implementations of singly-linked lists until I was blue in the face. It's nice to know how those things work, but it's also nice to know that reinventing the wheel is stupid when you're trying to get a program done on a budget; they could have mentioned that tidbit at least in passing.

Strangely I never had a single database class in college. I never learned SQL until I taught myself after I graduated. If anything I would think SQL is almost essential for any programmer to know. I never learned shell scripting along the lines of bash scripting or Perl as a shell scripting language.

How about Vim? Vim has contributed greatly to whatever productivity I have at work (and home) nowadays. But the one time I remember it being mentioned in college was a professor saying something about "this really old and weird editor called VEE EYE, anyone ever heard of it?". Left to my own devices, I always used the sucktastic Visual Studio IDE, since it was the best thing I knew existed at the time. I did have one good class (again taught by one of the crusty old Unix guys) where we discussed the importance of a good editor, how syntax highlighting and auto-indentation can help a coder catch errors and be more productive. I don't remember if Vim was mentioned by name, I think it was more an advocation of fancy IDEs along the lines of Visual Studio. But it was something I wish we'd have gone into more detail on.

The thing I probably value most from my formal education are the things that are the least practically useful. Theory of computation stuff. Compiler design, programming language design, things like that. State machines and grammars and string parsing. The history and evolution of programming languages. How programming languages work under the hood, garbage collection algorithms, object heaps and call stacks. Those were really interesting and I think helpful in understanding what's really going on when you write and run code. But I'm unsure how much it helps in a practical sense, when your boss says "Give me this by Friday".

I'd say only within the past year have I even begun to approach the level of "adequate" programmer in terms of skill level, and it's almost entirely thanks to things I've learned on my own since college. Maybe I'm misremembering, maybe college gave me some kind of magical foundation upon which all other knowledge has been built. Maybe there isn't enough time in college to learn the things I wish I had learned. I don't buy that.

There's no doubt the piece of paper saying that I graduated has helped me in practical ways, e.g. finding and getting a job. But I can't help but think that things I've learned privately just because I like learning them has been more useful in being able to actually do my job. On that note, having started in high school with hideous old QBASIC, ventured through C and C++, hurried past Java, gone down the Perl path for a long while, briefly glanced at the likes of Haskell and PHP and many others, and ended up firmly in Ruby territory, I'm planning to revisit C++ again a bit now. Maybe it'll all make more sense now. I ordered a book last week, we'll see how it looks once it gets here.

PHP design patterns?

Tue, 23 Jan 2007 18:44:48 -0800

As one of my professors used to say, "There's no problem that can't be solved by adding another layer of abstraction". He was joking, but there's a little bit of truth to that.

I've been working on my other website for a while. It's all PHP4, not entirely by my choice but I'm limited what can be installed on my server. PHP4 turned out to be a lot more powerful than I'd initially thought. Namely the OOP options available are mostly adequate and in a few places surprisingly OK. PHP has some nice meta-programming sorts of functions like get_func_args() and call_user_func() which let you play around with doing weird things dynamically at runtime, which were almost essential in putting all this crap together. It lacks the completeness or elegance of Ruby, and PHP's syntax is generally horrific and painful, but it'll do.

I recently read Head First Design Patterns which is quite a good book. I was able to use plenty of what I learned there in designing a sort of templating system for my other website. Basically I have tons and tons of tables of different sorts of data. CSS goes a long way to making the presentation of the tables easy to change given that they are properly marked-up, but actually marking them up properly and consistently was the problem.

So I put together a bunch of classes that generate HTML tables. One of the things from Design Patterns that really makes sense when you hear it is to lean toward composition rather than inheritance. In other words, an object that has another object as an instance variable is often easier to deal with than an object that inherits the same functionality from a parent class; the reason being that you can use polymorphism to your advantage, and have your object contain a member of a GENERIC type, and then you can give your object an object of any subtype of that generic type you want. So your class then does not depend on the type of its instance variable at all, so long as all possible objects that end up in that variable have the same interface. Loose coupling and all that.

I have used this to great advantage in adding flexibility in marking up table cells. A cell will be a different class (actually a different composition of lots of classes) depending on the kind of data it stores. A TextCell holds text, so I know to pad it and format it (differently than an ImageCell, or a cell containing an unordered list). I can composite TextCells with other more specific types; a value that represents a percentile is a PercentileCell; the class handles formatting the numeric value and sticking a % on the end. I could composite it with an ImportantCell which will give it a special background color. It's as simple as $cell = new TextCell( new ImportantCell( new PercentileCell( 56 ))); The nifty thing is that I can composite the cells arbitrarily in any order or combination, because each simply holds a generic "cell" member and calling a method on an object only causes it to call the same method on its child object, all the way down the stack. Also, if I later decide to take the % off the end of all my percentile values, I can do it by changing a single class definition. That's the kind of thing you can't handle well with HTML/CSS alone. Before, it'd take me a month and half to go mucking around in static HTML files fixing it all. (Or an hour worth of Perl regexing, but still, no fun.) Or if I want my HTML to validate as XHTML Strict, I can change the HTML for all my tables at once by screwing with the base Cell class. If I want to turn it into XML or some other markup, I could do that too, in theory.

At this point I'm essentially writing most of my pages entirely in PHP, never needing to write any raw HTML by hand at all, which is a very nice change of pace. I wish they'd have taught more of this sort of thing in college. We learned how to write searching and sorting algorithms until blue in the face. But we never really touched on how to design software at a very high level. I still think I'm not too good at it in many ways, but I'm learning, at least.

SCJP continued

Tue, 16 Jan 2007 23:53:47 -0800

Another SCJP study chapter down. I no longer feel bad about missing some questions in the last chapter, because THIS chapter is the one that talks about abstract classes being able to implement interfaces etc. Nice to ask questions about things before actually covering them.

Those silly default no-arg constructors in Java. I missed one review question about those. This is an example of the opposite of the "principle of least surprise" so touted in Perl and Ruby. Default constructors are magically automatically created in Java, but only if you don't supply any constructors of your own. Calls to superclass constructors are magically inserted in all constructors including those you define yourself, but they're always calls to super() with no arguments, and those super() calls aren't inserted into any constructor that calls another constructor as its first line. And so on and so forth.

Interesting that interfaces can extend multiple interfaces, while classes cannot extend multiple classes. One of the reasons behind forbidding multiple inheritance is supposedly so that you don't have to deal with method name collisions when multiple parent classes each let a child inherit methods with the same name. I tested what happens when there are name collisions in interfaces:

interface Blarg {
    public void test();
}

interface Blarg2 {
    public int test();
}

public class Test2 implements Blarg, Blarg2 {
    public void test() {}
    public static void main(String [] args) {}
}

It appears in this case there is no way to actually implement both the Blarg and Blarg2 interfaces in one class. (If there is, I can't see it.) You can't have two methods with the same name, same argument signature, and different return value. Trying to compile this fails with a "Hey you forgot to implement Blarg2's test() method" error. Similarly if I try

interface Blarg3 extends Blarg, Blarg2 {}

I get an error about Blarg and Blarg2 being "incompatible" because both define a method of the same name. That's handy. (Why not use the same error and allow multiple inheritance, and forbid it only whenever there are method name collisions? Who knows. Not I. I'm sure there are reasons. I hope there are reasons.)

I have a very good grasp on overriding vs. overloading. I remember going over it in my very first C++ class at college. I've somehow carried it all the way with me. Same goes with typecasting. Perl/Ruby don't have an equivalent, but I remember enough of it from C++. I also don't seem to have any trouble remembering which things happen at runtime and which things happen at compile-time. That should serve me well on the exam.

SCJP

Tue, 16 Jan 2007 00:20:32 -0800

I plan to move to the west coast sometime within a few months, and that means job searching. That means time to hunker down and get this SCJP overwith. I don't know if it'll help me find a job, but it can't hurt me. I'm going to keep track of what I learn here, and I'm going to write about things I found troublesome in hopes that the act of typing it will help me remember, and that I'll have some kind of record of it.

Today I went through one chapter, dealing mostly with Java class/method/member access modifiers. In the practice questions I missed a couple questions, which was depressing after having just studied it for nearly two hours.

One I missed because I didn't know abstract classes can implement interfaces. But it makes sense that when an abstract class DOES implement an interface, it doesn't need to provide all the methods in the interface.

Another I missed due to Java's screwy syntax. Java will supply an implicit public abstract on any methods in an interface, but when you implement those methods in a concrete class you have to specify them explicitly public. Otherwise they revert to default and that means they don't properly implement the interface's methods at all.

Similar to above, I forgot that even though an interface provides an implicit abstract to its methods, and abstract class does NOT. That makes sense after I think about it for a second, because abstract classes can contain both abstract AND non-abstract methods. However given that abstract and non-abstract methods have different syntax themselves (abstract methods end with a semicolon, and non-abstract methods end with curly braces containing or not containing code) you'd think the compiler could figure it out. But nope.

It's amazing how I studied Java for two years at college and I never got these kinds of rules spelled out in so many words. I sort of picked it up as I went. And I took a class on compiler theory / general computer language design theory, which helped IMMENSELY whenever I need to understand things like scoping rules and inheritance rules and parameter-passing methods. I think those very subtle things are one of the more difficult aspects of computer programming, especially because they differ so often between various programming languages.

Data

Mon, 19 Jun 2006 09:52:25 -0700

This will be one of my few "happy" rants.

I've known I wanted to be a code monkey since I was in high school. But if you'd asked me what I wanted to do back then, I'd have likely said "program games!" or "something flashy having to do with graphics!".

When I got to college and studied computer science, I was at first horrified to learn that most of computer science was pushing data around. A whole class on how to store data in hashes, stacks, and trees. Another whole class on how to sort data once it was in those structures. It was terribly boring to me at the time.

How interesting that pushing data around turned out to be so darned fascinating. I think perhaps it was boring because I was no good at it before. I just spent a couple days turning a flat HTML table into a normalized SQL table. A couple years ago I'd have sat there copying and pasting from one file into phpmyadmin. Now, I bang out some Perl, parse up the HTML, turn it into a SQL query, and run it. I'm probably at least an order of magnitude more productive now at nearly EVERYTHING than I was even a few years ago.

No matter what you want to do with computers, whether it be designing games or GUI design or web design or general software engineering or whatever, a huge part of it is going to end up being "playing with data". Getting data from here to there, and translating it along the way. Storing and organizing the data so that you can do something with it. Your source code itself is just another form of data, on one very important level. The fact that I find all this so much fun is possibly one of the reasons I so love Perl.