I think it's a fallacy to assume that anything not based in CS fundamentals is a fad or has only short-term value.
In college, I didn't learn version control, continuous integration (continuously submitting your work in small changelists or patches), unit testing, making sure you're building the right product before building it, delivering the simplest possible code and design that meets the requirements, code quality, working in teams, untangling dependencies and making as much progress as possible today without waiting for all your dependencies to be resolved, and so on.
I expect that all these skills will be very much relevant 20 years from now. So, don't confuse long-term value with "grounded in CS fundamentals". Programming isn't a hard science like physics.
>I think it's a fallacy to assume that anything not based in CS fundamentals is a fad or has only short-term value.
I didn't say that. I said most industry processes are fads. I also didn't say that nothing that isn't grounded in CS fundamentals has long term value.
There are plenty of other skills that have long term value. Office politics, salary negotiation, self-promotion are much more valuable than knowing how to run a few git commands. But non of those things should be taught in a Computer Science program.
They are fundamentally vocational skills. Just like version control, unit testing, and continuous integration are vocational skills. Sure they're useful but they should be taught in an internship/apprenticeship or on the job.
>In college, I didn't learn version control...
I learned to use subversion, and other than the fact that they are are both version control systems, what I learned didn't really carry over to distributed version control like Git.
In a CS program you should be learning things like how to implement a version control system, not how to use Git. I would have been pissed paying thousands of dollars per semester for a professor to walk me through a Git tutorial.
I don't have a problem if a professor wants you to use github to submit your assignments or something like that. And sure some of the vocational skills you listed are going to be useful for years to come. But these skills should be ancillary. They should be just a happy side effect--like learning teamwork during a group project.
I'm a practician, not a theorist or an academic. I couldn't care less whether something is based in CS theory. I care whether something will be useful to me over the course of my career. If it is, I'd like my education to train me for that.
In fact, some of the academic stuff like compilers and automata have been useless in real life. That's a failing of academia from my point of view.
That's perfectly fine. What you're looking for is vocational training, not a liberal college education. Non professional college programs are explicitly not vocational training. If they were, they wouldn't require spending nearly half your time on general education requirements (assuming we're talking about the US here). I doubt art history, physics, or psychology has proven much direct use to you in your career.
>In fact, some of the academic stuff like compilers and automata have been useless in real life. That's a failing of academia from my point of view.
Finite state machines and pushdown automata are an incredibly common pattern, and I can't see how you can work as a professional software developer without running into that pattern time and again. Have you never used regular expressions?
Automata (usually taught along with theory of computation) teaches you all kinds of useful real world knowledge, like why you can't parse HTML with regular expressions, and why you can't write a program to tell if another program will eventually halt.
My idea of education is one that teaches you skills that are broadly used throughout your career. I don't a priori reject things that meet this criteria just because it's not based in theory (because theory is not an end to itself), or by applying arbitrary labels like "vocational" (whatever that means), "liberal" or "professional".
As for art history and psychology, that's a different debate to be had about education — whether these should be part of education and how much time they should take.
As for your question, I've used regexes, but you don't need to understand the details of the regex engine in order to use them. Neither do I, in my day-to-day work, write programs that try to tell if other programs halt.
>but you don't need to understand the details of the regex engine in order to use them.
Yes, at some point you do. Without understanding how regular expressions actually work, you can't know when it is appropriate to use them. Many things aren't possible with regular expressions and many grammars aren't parsable with regular expressions. You can either waste time trying to write an impossible regex (or write one that works on your tests, but blows up in the wild) or you can study automata theory and understand what actually goes on underneath.
As for the halting problem, I'll leave you this stack overflow explanation for why it is beneficial to understand.
Many problems in CS have already been solved, some are impossible to solve. You can either waste time on trial and error trying to reinvent the wheel or you can study the theoretical underpinnings.
Do you want to spend a week trying to model a problem as a finite state machine, only to determine that finite state machine isn't powerful enough to solve your problem?
Do you want to spend a month banging your head against a wall trying to solve a problem that you could have solved in 5 minutes had you realized it was just a well known graph theory problem all along? A problem that was solved decades ago. The only way to know these things is to study the theory behind what you do.
Why do you think Civil Engineers are required to take physics? The difference between an Engineer and an artisan is a rigorous understanding of the formal system underpinning his work. Artisans build through trial and error and experiences, and they leave many failed projects in their wake while they gain this experience. Engineers use theory and modeling to limit the number of failed projects to the net benefit of everyone involved.
> My idea of education is one that teaches you skills that are broadly used throughout your career. ... applying arbitrary labels like "vocational" (whatever that means)
vocational - adj.
2. (of education or training) directed at a particular occupation and its skills.
Which is exactly your idea of education. The labels are descriptive, not arbitrary.
Then, do not go for a degree in Computer Science if that is all you want. I am sure there are cheaper and better ways to become a practician than going through college.
Becoming a software developer is just one of the possible career options after a CS degree.
I doubt that there are cheaper and better ways to become a practician than going through college. In India, where I live, most companies are not interested in you unless you have a degree. The normal path to a career in programming is to get a CS degree. And the normal outcome from a CS degree is a career in tech. So, they are much more closely related than you acknowledge, at least in my part of the world (things may be different in yours).
Yes, it happens also in Spain: companies want college degrees for their software factories, and at the same time complain that colleges do not teach anything useful.
In college, I didn't learn version control, continuous integration (continuously submitting your work in small changelists or patches), unit testing, making sure you're building the right product before building it, delivering the simplest possible code and design that meets the requirements, code quality, working in teams, untangling dependencies and making as much progress as possible today without waiting for all your dependencies to be resolved, and so on.
I expect that all these skills will be very much relevant 20 years from now. So, don't confuse long-term value with "grounded in CS fundamentals". Programming isn't a hard science like physics.