The gap between industry and academia is huge.
My suggestion for a future professional would be to learn very good coding because without that skill people are very limited.
What I have seen in practice is that it's impossible to gauge how useful an algorithm/method is without trying it out first, so the most important skill is the skill to do try different things out quickly, a.k.a. coding.
What I tell my developers and optimisation specialists is to work smart, not hard - this means writing tools to automate anything that is time consuming and needs to be done more than once, because we need to try many different things to see what works. We have tools for generating symbolic decompositions automatically, distributing calculations over a cluster, scripting reformulations, testing, benchmarking, etc. Basically, if we can imagine it, it's either built, being built, or scheduled to be built.
Methods
For large-scale systems, modern methods focus on lowering memory requirements or distributing memory among many machines.
If the reason the problem is large is that it's very dense, and not because it has a trillion variables, then:
- For NLPs, fast gradient methods are state of the art (e.g., the fast proximal gradient method).
- For LPs, interior point is still the king if the system is very large.
- For MI(N)LPs, people focus on distributing the calculations for traditional methods, e.g., generate the bender's decomposition and use many parallel workers to solve the subproblems.
- Where branch-and-bound is applicable, using a hierarchical multiple manager-worker system to process nodes and create branch-and-bound subtrees in parallel like in PARASCIP or Octeract Engine.
If a system has so many variables that we can't fit it into memory, people are unlikely to use deterministic methods in practice, and will try stochastic stuff instead (e.g., evolutionary algorithms or PSO).
In general, the main differentiator nowadays is not theory, but figuring out how to implement it properly using parallel hardware. Unfortunately, this is not what academic research is designed to disseminate, which brings me to the "what I think of this claim" part of your question:
Industrial adoption
Software-wise, industrial software is light years ahead of any academic code in terms of performance, robustness, and reliability. CPLEX/GUROBI vs CBC is a great example of this.
Theory-wise, it's hard to tell. While a lot of amazing theoretical work has been done in academia over the past three decades, maybe 0.01% of it has found its way to actual application.
As a former academic, my conclusion was that the reason is the way the academic system is designed, which is why I left academia.
The academic reality
The central fallacy is that professors believe that PhD students can write professional-grade software. They can't. As a former PhD student myself, I realised this when I hired our first professional developer. There is simply no comparison between what people who write code for a living and the rest of us can do. My development work is mostly in the R&D, i.e., to prototype new features and to do algorithmic optimisations for performance. My code eventually goes to our developers who turn it into proper code. It's not that my code is bad, it's just not efficient for me to spend two months designing something properly. I do the things only I can do, and the developers do the things only they can do, and that is how it should be done nowadays.
Coding has advanced a lot since the 90's, so asking a theorist to write good code is not as straightforward as it was 30 years ago, but most professors still think that way, maybe because this was kind of true when they were students. There was less to know.
Because of the overwhelming growth in coding techniques and tools, asking students to write good (by today's standards) code is the equivalent of expecting an experimentalist to know as much as the theorists and the developers. It's simply too much for any one person.
This is a very practical issue because, at the end of the day, applied math is pointless unless implemented into software. This becomes trickier if we consider that it's very hard to properly compare the runtime behaviour of two algorithms unless both are professionally implemented. If there is a flaw in implementation, an algorithm can easily be 1,000,000 times slower than it could. If there is a bug because there is no testing framework in place, an algorithm can be 1,000,000 faster instead.
Developing software properly costs money, time, and requires hiring professional developers. Unfortunately, only a handful of universities world-wide are willing to make that investment.
The systemic issue is that academics are not rewarded by the system for producing good, tested, and reusable software. In fact they are actively discouraged because their h-index will not be as high (5 years of development for one good publication vs 4-5 theoretical papers a year).
The result
As a result, we have software to solve optimisation problems, but we still lack proper tools and libraries for developing new optimisation software quickly and correctly. This stagnates experimentation, is in the way of proper testing, and so on.
Everything anyone implements needs to be done pretty much from scratch. The COIN-OR project was an amazing idea that tried to address this, however the overwhelming majority of code in the projects is not reusable either because (i) it's unreadable so it can only be used as a black box (e.g., CBC/IPOPT), or (ii) it's unreadable and buggy, so it can't be used at all because no-one can read the code to fix it, or (iii) is really good but almost completely undocumented (e.g., CBC).
Don't get me wrong, some of the COIN-OR/open-source stuff is really good, it's simply rarely designed to be a true open source collaborative project, because it's driven by academics instead of coders. It's usually the code someone wrote and generously decided to share with others. The difference between OR code and other popular open source projects is actually staggering - there is a reason Tensorflow has 56,000 watchers on github and IPOPT only has 16.
