The recent passing of Cleve Moler at 86 triggered the predictable wave of hagiography across tech journalism. Obituaries painted a cozy picture: the benevolent professor who built MATLAB to save his students from the horrors of Fortran, single-handedly democratizing computing for millions of engineers.
It is a beautiful narrative. It is also fundamentally wrong.
Cleve Moler was an undeniable mathematical brilliant, and his work on LINPACK and EISPACK laid the bedrock for modern numerical analysis. But the corporate empire that grew from his university scratchpad—MathWorks and its flagship product, MATLAB—did not unlock the power of computing. It locked it in a proprietary sandbox. By shielding generations of engineers and scientists from the foundational realities of software engineering, MATLAB created a massive technical debt that the scientific community is still paying off today.
We did not democratize computing. We institutionalized a crutch.
The Matrix Laboratory Fallacy
To understand where the consensus goes sideways, you have to look at what MATLAB actually did. In the late 1970s, Moler wanted his students at the University of New Mexico to use LINPACK without writing tedious Fortran boilerplate. He created a conversational interface where everything was implicitly a matrix.
The tech press calls this a revolution in accessibility. In reality, it was the birth of an anti-pattern.
By turning every variable into a two-dimensional array of double-precision floats by default, MATLAB simplified early linear algebra coursework at the expense of computational literacy. Generations of civil, mechanical, and aerospace engineers graduated believing that memory management, data structures, and type definitions were trivialities to be ignored.
I have watched aerospace enterprises throw millions of dollars down the drain trying to port fragile, unoptimized MATLAB scripts into production-ready C++ for flight hardware. The scripts work fine in a idealized vacuum on a high-end workstation. They fall apart completely when subjected to the constraints of real-world embedded systems.
The tool taught engineers to think in terms of mathematical equations rather than computational complexity. It obscured the physical reality of how silicon actually processes data.
The Closed-Source Tax on Scientific Progress
The standard tribute praises MATLAB for driving scientific discovery. This completely ignores the systemic chokehold that MathWorks maintains over academia and industry through predatory licensing.
Science requires reproducibility. True reproducibility requires open access to the tools of verification. For decades, breakthroughs in signal processing, control systems, and image analysis were published alongside proprietary .m files that could only be executed by institutions wealthy enough to afford thousands of dollars per seat in licensing fees.
Consider the baseline mathematics involved. To solve a simple system of linear equations:
$$Ax = b$$
In MATLAB, this is achieved using the backslash operator: x = A \ b.
Behind that single character lies a complex, automated decision tree. It checks if the matrix is sparse, symmetric, banded, or triangular, then routes the data to the appropriate LAPACK routine. It is incredibly convenient. But because the underlying engine is a closed-source black box, researchers for decades could not inspect the exact implementation details or edge-case handling without violating EULAs or relying on faith.
We traded the transparent rigor of open science for the convenience of a commercial monopoly. The rise of Python, NumPy, and Julia over the last decade isn't a natural evolution; it is a desperate, ongoing prison break by scientists realizing they had locked their intellectual property inside a corporate walled garden.
Dismantling the "Python is Just as Bad" Defense
When confronted with the sheer weight of MATLAB’s baggage, defenders invariably point to the modern state of scientific computing. They argue that Python, with its sprawling ecosystem of NumPy, SciPy, and pandas, is just as abstracted, slow, and messy.
This argument misses the point entirely.
Python is a general-purpose language that embraces modern software engineering principles. It supports object-oriented programming, robust exception handling, native package management, and seamless integration with version control systems like Git.
MATLAB, for the vast majority of its lifespan, treated these foundational concepts as afterthoughts. Version control in MATLAB historically meant saving files as analysis_v2_final_fixed.m. Writing modular, testable code was actively discouraged by an architecture that favored monolithic scripts and a messy global workspace.
Furthermore, Python’s core scientific stack is open. If a researcher wants to know exactly how a fast Fourier transform is being calculated, they can dive directly into the C source code of NumPy. With MATLAB, you wait for the next annual release and pay your maintenance fees.
The Industrial Hangover
The damage isn't confined to university labs. It is deeply embedded in the industrial complex.
Automotive and aerospace giants are trapped in a codependent relationship with MathWorks products like Simulink for model-based design. The promise was alluring: draw a flowchart, click a button, and automatically generate production code.
Ask any software engineer who has had to debug auto-generated C code from a Simulink model about their sanity. The output is a bloated, unreadable labyrinth of global variables and nested conditionals that defies static analysis and balloon safety certification costs.
We replaced the skilled craft of writing clean, explicit code with the lazy habit of wiring together graphical blocks. We created a class of engineers who can design a control loop on a canvas but cannot read a memory map or explain a stack overflow.
The Actionable Pivot for Technical Leaders
If you are running an engineering team, a research lab, or a department, the path forward requires breaking the cycle of comfortable inertia.
- Audit Your Licensing Spend: Calculate the exact dollar amount your organization spends annually on MathWorks licenses and toolboxes. Divert 30% of that capital to fund internal training for modern languages like Julia or Python.
- Enforce Production Standards Early: Ban the practice of throwing prototype scripts over the wall to the software team. If an engineer writes an algorithm, they must be capable of implementing it within the target environment's memory and performance constraints.
- Embrace Explicit Computation: Stop relying on magical, multi-layered abstractions for core proprietary logic. If your business depends on a specific numerical solver, your team needs to understand the exact flavor of LU decomposition or conjugate gradient method being used under the hood.
The legacy of the early computing era shouldn't be the blind worship of tools that made life easy in 1980. Cleve Moler solved a temporary problem for a specific generation of students. By treating his stopgap solution as a permanent paradigm, we stunted the software literacy of the entire engineering world. It is time to put the training wheels away.
