The thing about algorithms is that you need to understand what they're for and how fast they are, but you usually don't need to implement them yourself. In many cases, someone else has already implemented the thing better than you could, and all you have to do is use it.
My experience as a programmer might be quite different from most people, since I do nothing but write algorithms. (And in fact, at first I was confused at how someone could enjoy programming but dislike algorithms... then I remembered there was other stuff you can do with your computer beyond solving mathematical problems and pester the TrekBBS )
I'll keep this simple: 1. Sit down and make a list of the activities you really love to do. 2. Go to a college check out the programs.
It's certainly true that some algorithms are too esoteric to have widely-used implementations available, and research can of course impose requirements too specific to be easily captured by a general framework. Even then, though, some of the building blocks will probably be more common algorithms you don't have to recreate. For instance, there's no reason to ever write a binary search in C++ when you can use std::lower_bound instead.
Thank you all for the feedback - especially those of you within the field. After working through this bout of uncertainty and really asking myself if I want to pursue this, I've come to the conclusion that - yes, I do. I think perhaps other factors like feeling a bit out of sorts as one of the mature students and other peripheral things might have had more of an impact than I was aware of. I feel like I owe algorithms an apology. Sorry, al. We've started on different sorting methods and it's actually quite interesting. Given what I've seen of the other languages, I agree. Java is the language of choice in next year's software engineering course. C is taught in the Operating System/Embedded System course.
Change majors. Or just screw school all together for being a waste of time and money that you will never get back.
When you start exploring multiple languages, keep in mind that each language has its own set of best practices. Just because two languages allow you to do similar things doesn't mean you should. For instance, Java wants you to do all your error handling via exceptions, where C++ prefers you to use error codes in most cases. Java requires you to use the "new" keyword a lot; in C++ this should be avoided. In Java resource cleanup is done in finally blocks (or, rarely, finalize methods); in C++ it's done in destructors.
One thing Python doesn't teach you is the advantage of a strong type system. In python, you usually won't discover bugs until you try to run your code. Interpreted languages almost all have this downside. A good type system allows you to discover many bugs at compile time instead. Some will still make it through that step undetected, but those decrease the more you leverage the type system. In some of the most strongly-typed languages, it's almost impossible to write a program that compiles but doesn't work. Java has a decent amount of type-checking, especially if you use generics, but older versions of it had a lot less type safety and attempts to maintain compatibility with those have crippled the type system in places. C has only minimal type safety. You have to pay attention to what you're doing to use it. C++ has a lot more type safety available, but only if you choose to use it (I recommend you do).
Do they still cover assembly language at all, in any computer science courses these days? (I still do most of my computer programming in C, largely out of habit).
Initially I started off majoring in engineering, hoping to move into computer type areas. At the time, I also naively subscribed to the foolish notion that computer type work was "easy street" on the job market. (ie. I was doing it for the money and lifestyle). After two years of intense general engineering courses (ie. a lot of "weedout" type courses that all engineering majors enrolled in), I found that I was more interested in electronics than computer programming. So I ended up taking further electrical engineering (EE) courses, and some optional physics courses in my junior year. (We had to choose a direction by junior year). By the end of junior year, I found that electronics wasn't as exciting as I thought it would be. But physics seemed to become more interesting. Since I didn't want to throw everything away, I ended up finishing the electrical engineering degree program in my senior year, along with taking several more optional physics courses. (I later found out physics at the cutting edge after undergrad, is a lot messier than what one sees in a textbook).
Yes, but only in a few classes. And it tends to focus more on understanding it than writing it. I like C++ because it gives me the power and speed of C, but drastically reduces the boilerplate required.
Assembly language is one of the things that pushed me away from Computer Science. (shudder) That said, I could never entirely figure out how much of it was the subject itself vs. the manner in which it was being presented to me. I hit similar roadblocks with Calculus actually...I could understand what the professor was saying and follow along and all, but I had a lot of trouble reproducing it on my own.
A common problem, and one that has taken many students by surprise when exam time arrives. As with most things, it comes down to practice.
^^^ I remember in freshman engineering, our computer classes consisted of mostly writing numerical algorithms in Fortran. Stuff like writing a computer program to find roots of equations, Gaussian elimination, generating random numbers, etc ... In sophomore engineering, our computer classes was mostly writing programs in x86 assembly language. Back then, every engineering major had to take these tedious mandatory computer courses as a part of the general engineering program in freshman and sophomore year. (I never took any courses which used C. I had to figure it out myself years later).
These days, things like that are usually just pulled from libraries. Often the standard library, in fact. There's plenty of value in understanding how to do mathematical programming, of course, but there is also a growing recognition that constantly reinventing the basic building blocks is a waste of time and resources.
Back then, every engineering major had to take these tedious mandatory computer courses as a part of the general engineering program in freshman and sophomore year. They were basically "weed out" type courses, to keep the engineering majors "busy" and to thin out the herd. IIRC, there were numerous F final grades at the end of the term for these tedious mandatory computer courses. I don't know if they still do it these days, but back when I was in college the engineering departments' intentions were to kick out as many engineering majors as possible in the freshman and sophomore years.