I disagree that they should phase out imperative / OO programming, but from my experience more emphasis on different languages i.e. throw in a ML (as in Meta Language) and a Lisp, and most importantly some information about the trade offs.
However it would require a culture shift as a university being a place to get you ready for a career in industry rather than academia.
Because you are prepping for academia it is OK for them to postpone functional to later years on even the PhD.
You mention grief with OO - but I think a lot of it you would get with Functional too and it has more to do with the incentives and people structures in organisations that produce code. Usually praise goes to those who get a 8 hour Jira ticket done in 4, or a 5 week task done in 4 weeks etc, and from the users point of view 'it works'. The structure of the code is not discovered until later.
Code reviewers are working at the deckchairs level, they are unable to change the Titanic's direction, and again both parties in a code review have incentive to do it as quick as possible (while not looking like they obviously brushed over it), so it become mostly a potential bug hunting and syntactic cleanup exercise.
It's almost a running joke that refactoring rarely gets done, and if it does it is trivial, and usually required some stealth from a developer or manager to create cover to do the refactor.
The only hope we have is to work somewhere where there is a good understanding of code quality from top to bottom in the org, or at least when you cross the technical/non-technical boundary there is a high degree of trust to let the tech people do the right thing, and not KPI them into submission.
You summed it up nicely. After writing my comment, I realized that imperative programming is so much more difficult than functional programming that in a way, it's the majority of the work of programming. Anyone can learn to use a spreadsheet, but it takes years of dedication to master debugging enterprise software. So there will always be huge demand for that skill, and so colleges should probably continue building it in students.
I'm still in mourning though imagining how far programmers could go if they weren't stuck endlessly debugging imperative code that will never be deterministic or free of side effects. Lots of lost potential there. I'm coming up on 3 decades of experience doing that and it feels like well over 90% of the code I've written was a waste of time. I guess it paid the bills though.
> I realized that imperative programming is so much more difficult than functional programming that in a way, it's the majority of the work of programming. Anyone can learn to use a spreadsheet, but it takes years of dedication to master debugging enterprise software.
Anyone can learn to program spreadsheets, because spreadsheets realize that state is the most important thing, and puts it front and center—hiding the calculations. Most programming paradigms are about manipulating the calculations, and the state is only visible when the program is running. As long as programming tries to avoid state, it'll be hard for most people to learn.
What you just said really struck a chord with me. I do tend to ignore state because it's less accessible. The result is that my code gets more esoteric and abstract while the changes I need to make to state come very slowly. On the other hand I've made spreadsheets as complicated as small applications I've made, but the cognitive load feels significantly lighter.
How can we bring state forward during development?
> from my experience more emphasis on different languages i.e. throw in a ML (as in Meta Language) and a Lisp, and most importantly some information about the trade offs
Most CS curricula have a course where you spend time programming in a variety of different programming languages, in different paradigms.
> Code reviewers are working at the deckchairs level, they are unable to change the Titanic's direction, and again both parties in a code review have incentive to do it as quick as possible (while not looking like they obviously brushed over it), so it become mostly a potential bug hunting and syntactic cleanup exercise.
And that's why I despise code reviews. There's obviously not enough time allocated to them for in-depth understanding of the reviewed code, so I'm mostly spending precious resources (attention, energy) on doing a half-assed review that is not going to do that much good. It feels like such futile work.
However it would require a culture shift as a university being a place to get you ready for a career in industry rather than academia.
Because you are prepping for academia it is OK for them to postpone functional to later years on even the PhD.
You mention grief with OO - but I think a lot of it you would get with Functional too and it has more to do with the incentives and people structures in organisations that produce code. Usually praise goes to those who get a 8 hour Jira ticket done in 4, or a 5 week task done in 4 weeks etc, and from the users point of view 'it works'. The structure of the code is not discovered until later.
Code reviewers are working at the deckchairs level, they are unable to change the Titanic's direction, and again both parties in a code review have incentive to do it as quick as possible (while not looking like they obviously brushed over it), so it become mostly a potential bug hunting and syntactic cleanup exercise.
It's almost a running joke that refactoring rarely gets done, and if it does it is trivial, and usually required some stealth from a developer or manager to create cover to do the refactor.
The only hope we have is to work somewhere where there is a good understanding of code quality from top to bottom in the org, or at least when you cross the technical/non-technical boundary there is a high degree of trust to let the tech people do the right thing, and not KPI them into submission.