MATLAB (R2026a)

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

1 Assessment

This page assesses MATLAB in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 39/100 · Ecosystem coupling 61/100 · Engineering readiness 42/100

1.1 Core coupling

1.1.1 Type

  • ❌ Dynamic typing with no static check (T1): A variable takes its type from the value assigned to it, so a type error is reported only when the statement runs
  • ⚠️ A numeric value carries a class but no shape: double is the default for a literal, and a 1×1 scalar, a vector, and a matrix are the same class, so the type does not state the dimensions the algorithm needs
  • ⚠️ Cell arrays and structs are weak structural types: They group heterogeneous values but declare no schema, so a consumer learns a struct’s fields from the code that fills it
  • ⚠️ Only a package folder scopes a name: A +pkg folder gives its functions and classes their own namespace, but a plain function or script on the search path shares one flat name space with every other file on the path, so a collision is resolved by path order
  • ⚠️ Argument validation is opt-in: An arguments block (R2019b+) checks class, size, and shape at call time, but a function without one accepts anything

1.1.2 Construction

  • ✅ Toolboxes separate domain computation from the core language: Signal Processing, Control System, and Image Processing operations are ordinary function calls, so an algorithm does not embed its own filter or transform code
  • ✅ A classdef file groups state with its operations: Properties and methods are declared in one unit, so a consumer binds to the class name
  • ❌ Global mutable state by default (C1): The base workspace and every shared function workspace hold variables that running code can read and overwrite at any time
  • ❌ No immutability by default (C2): Every array is mutable, and there is no const-like freeze for ordinary data
  • ⚠️ Constructors are ordinary methods with no enforced invariant: A class defines its own Name(...) constructor, so a well-formed instance depends on the author’s validation
  • ⚠️ Scripts run in the caller’s workspace: A variable a script creates stays in the caller after the script returns, so a script couples to every caller’s variable names

1.1.3 Memory

  • ✅ Copy-on-modify protects the reader: An assignment copies a value only when the copy is modified, so a function that receives an array does not change the caller’s value
  • ⚠️ The collector runs on its own schedule (M2): Memory returns when the interpreter decides, so release timing is not owned by the code
  • ❌ No RAII (M3): There is no block-scoped destructor, so a file handle, timer, or instrument connection stays open until delete or an onCleanup object runs
  • ❌ No ownership model (M4): No static lifetime or aliasing rule ties an array’s storage to one owner
  • ⚠️ clear and pack are manual controls: Freeing a large array and defragmenting the workspace are explicit calls, so the memory strategy is the programmer’s

1.1.4 Error

  • ✅ try/catch gives a structured recovery path: A catch block receives the MException object, with its identifier, message, and stack, so recovery need not parse text
  • ✅ error takes a stable identifier: error('pkg:func:reason', ...) sets MException.identifier, so a caller can branch on the code rather than on the message
  • ❌ Unchecked exceptions only (Er2): A raised MException travels up until something catches it or the program stops, and no caller is required to handle it
  • ⚠️ An empty catch is common in legacy code: A catch block with no body discards the failure without a trace
  • ⚠️ Many failures are detected only at run time: An out-of-bound index, a class mismatch, or a singular matrix is reported when the statement executes

1.1.5 Concurrency

  • ⚠️ Manual synchronisation with no race detection (K3): parfor, spmd, and parfeval leave the shared-variable reasoning to the programmer, and the language reports no data race
  • ✅ parfor separates loop iterations: An independent loop is split across workers, so iteration order is not part of the result
  • ✅ labSend and labReceive pass data between spmd workers: A worker sends a value to a named peer instead of writing into shared memory
  • ⚠️ The parallel constructs need the Parallel Computing Toolbox: parfor, distributed arrays, and parpool are a separate licensed product
  • ⚠️ A captured variable is broadcast to every worker: A parfor body sees a copy of the outer variable, and a reduction must use a supported form or a temporary variable

1.1.6 Platform

  • ✅ GNU Octave is a compatible open implementation: Most MATLAB programs run under Octave, so a project is not bound to one vendor’s binary alone
  • ⚠️ A licence still governs the base product: An installation of MATLAB itself needs a licence, so deployment and continuous integration depend on MathWorks’ terms and pricing
  • ⚠️ Toolbox coverage is proprietary: Domain functions come from licensed MathWorks toolboxes, so portability depends on which toolboxes the code calls
  • ⚠️ A compiled component still needs the MATLAB Runtime: MATLAB Compiler builds a library callable from C, C++, .NET, or Python, but the component runs against a version-matched MATLAB Runtime

1.1.7 Trade-offs (not coupling)

  • One-based indexing is a convention choice: Starting an array at index 1 is a documented decision, and the cost is re-learning for a user who comes from a zero-based language
  • The global workspace suits interactive work: A session-wide namespace is convenient at the command line, and the coupling it creates at scale follows from using session state as program state
  • Everything-is-an-array is a deliberate uniformity: One container for scalars, vectors, matrices, and N-D arrays keeps the language small, and the loss of shape in the type is the price
  • The filename rule is a lookup convention: A function file is named for its entry point, and local functions in scripts (a later addition) reduce the constraint
  • A proprietary platform is traded for an integrated toolchain: The licence buys one install, one editor, and one support channel
  • Scripts are for session-scale tasks: Converting a script to a function removes the caller-workspace coupling

1.2 Ecosystem coupling

1.2.1 Performance

  • ✅ Matrix expressions call tuned BLAS and LAPACK libraries: A*B, A\b, and fft run in compiled libraries, so numerical throughput does not depend on hand-written loops
  • ✅ Vectorisation removes per-element interpreter overhead: One array expression is one interpreted call, whatever the element count
  • ⚠️ The interpreter performs no ahead-of-time compilation (R1): Base MATLAB executes an interpreted form, so a loop that cannot be vectorised is slower than its compiled equivalent
  • ✅ The execution engine compiles eligible code just in time: The engine introduced in R2015b accelerates a repeated loop after warm-up
  • ⚠️ Speed follows the shipped library, not the source: The cost of a signal-processing or control operation depends on the toolbox build and on the CPU it was tuned for

1.2.2 Ecosystem

  • ❌ The ecosystem is proprietary (Ec4): Toolboxes, the editor, and the reference documentation come from one vendor under licence
  • ✅ The toolbox library covers most engineering fields: Optimization, Statistics and Machine Learning, Signal Processing, and Control System toolboxes are long-established products
  • ✅ The Add-On Explorer installs packages by name: MathWorks and community add-ons are installed through one manager, so a project does not have to vendor source
  • ✅ MATLAB Central File Exchange is a large community index: User-contributed functions and toolboxes are published together and searchable
  • ⚠️ Toolboxes ship in lockstep with the release: A toolbox is versioned for the MATLAB release it targets, so an upgrade can require every toolbox to move
  • ⚠️ Every tool in the chain assumes a licensed installation: Editors and continuous-integration integrations exist, but they resolve back to a licensed MATLAB

1.2.3 Evolution

  • ✅ Backward compatibility is a stated commitment: MathWorks keeps old syntax working and warns before a feature is removed, so a program from an earlier release generally still runs
  • ✅ Two releases a year on a known cadence: R2026a and R2026b follow a predictable schedule, so an upgrade path can be planned
  • ✅ verLessThan lets one source span two releases: A program can branch on the MATLAB version, so an old and a new release can be supported together
  • ⚠️ An upgrade can change performance or a default: A new execution engine, a new library version, or a changed default can alter timing or output for code that relied on the old behaviour
  • ⚠️ A deprecated function may stop working later: Deprecation is announced, but a function or toolbox marked for removal eventually goes away

1.2.4 Domain

  • ✅ Excellent fit for numerical linear algebra: Matrix syntax, \ for a linear solve, and N-D arrays match the mathematics directly
  • ✅ Signal processing, control systems, and image processing are first-class domains: Each ships as an endorsed toolbox with the reference algorithms
  • ❌ Domain and vendor lock-in (D1): The language and its library set target one vendor’s platform, so adoption is also a procurement decision
  • ⚠️ Simulink is a second modelling toolchain: A graphical model is not MATLAB source, so a control design that uses Simulink couples to a second product and file format
  • ⚠️ General application work sits outside the design centre: File handling, text processing, and network code read as additions to a numerical language

1.2.5 Learning

  • ⚠️ Moderate at the start and steeper later (L1): A\b and 1:n are learnable in days, while vectorisation, the workspace model, and copy semantics take practice
  • ⚠️ The workspace model confuses newcomers: A variable a script creates persists in the caller, so a beginner cannot tell where state lives
  • ⚠️ One-based indexing diverges from most languages: Code ported from a C-family or Python source needs every index checked by hand
  • ✅ Documentation is uniform and complete: Every function has a reference page with examples, and the language is taught in standard textbooks
  • ⚠️ Toolbox knowledge is separate from language knowledge: Finding the right function means knowing which toolbox owns the domain

1.2.6 Syntax

  • ✅ Matrix-oriented and compact: A(:, 2) = A(:, 1) * 3; expresses a whole-column operation in one statement
  • ✅ Keyword-light and readable: Most statements are operations on data, with few punctuation-only constructs
  • ⚠️ Element-wise and matrix operators differ by one dot: * versus .* and ^ versus .^ are distinct operations, so a missing dot silently changes the computation
  • ⚠️ end is overloaded: It terminates a block and marks the last index inside a subscript
  • ⚠️ The semicolon controls output rather than the statement: A missing ; prints every intermediate result, which clutters a long run

1.2.7 Testing

  • ✅ A test framework ships in the base product: matlab.unittest.TestCase, functiontests, and runtests provide assertions, fixtures, and parameterised cases
  • ✅ A failure reports the value and the assertion: The framework prints the constraint that failed and the observed value, so a failure is localised
  • ✅ Mocking and coverage are part of the framework: matlab.mock creates replacement objects, and the code-coverage plugin reports unexecuted lines
  • ⚠️ A test suite lives in function files beside the code: There is no separate test manifest, so a suite’s scope follows the folder layout
  • ⚠️ Automated runs need a licence: Continuous integration needs a licence seat or a pre-built component with the MATLAB Runtime

1.2.8 Security

  • ✅ No pointers and no manual memory access: The language offers no address arithmetic, so a buffer overflow cannot be written in MATLAB source
  • ✅ External access is explicit in the source: fopen, readmatrix, and webread are visible calls, so a reader can see every file and network access
  • ⚠️ eval, evalin, and str2func execute text as code: A string built from untrusted input can become a statement, which is the injection pattern
  • ⚠️ load can introduce undeclared variables: Restoring a .mat file creates variables whose names the source does not state, and such a name can shadow a live variable
  • ⚠️ Static proof of run-time error freedom needs a separate product: Polyspace Code Prover proves the absence of certain run-time errors, but it is licensed apart from the language

1.3 Engineering readiness

1.3.1 Reproducibility

  • ❌ Builds are not byte-reproducible by default.
  • ❌ Dependencies resolve without a lock by default.

1.3.2 Supply chain

  • ⚠️ Published packages carry no signed provenance by default.
  • ⚠️ The package registry is a flat name space.

1.3.3 Observability

  • ⚠️ No stable tracing and metrics standard.
  • ⚠️ The standard library has no structured logging.

1.3.4 Feedback

  • ✅ No charged mechanism in this dimension.

1.3.5 Interop

  • ⚠️ No maintained portable target.

1.3.6 Governance

  • ⚠️ One vendor decides the language’s direction.
  • ⚠️ The specification is not public.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

  • ⚠️ Runs on a virtual machine, above native code in the energy and time benchmarks [5]; a causal re-analysis attributes most of the gap to execution time [6].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

  • ⚠️ Moderate training data: models write it competently, with measurable language-specific weakness [7].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

  • ⚠️ No certified or standards-qualified path for safety-critical systems.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension Mechanism Description Present Cost
Type T1 dynamic no static check ✅ −15
T2 weak static — 0
T3 dynamic/duck dispatch — 0
T4 no sum types — 0
T5 no generics — 0
T6 no namespaces — 0
T7 type erasure/reflection — 0
T8 operator overloading — 0
T9 inheritance required for polymorphism — 0
T10 no null-safety — 0
T11 no module boundary — 0
T12 no effect tracking ✅ −8
T13 async/sync colouring — 0
T14 unchecked foreign boundary ✅ −4
Type subtotal −15 (−27)
Construction C1 global mutable state by default ✅ −15
C2 no immutability by default ✅ −4
C3 constructors coupled to allocation — 0
C4 no constructor/validation — 0
Construction subtotal −15 (−19)
Memory M1 manual deallocation — 0
M2 GC non-deterministic pauses ✅ −8
M3 no RAII ✅ −4
M4 no ownership model ✅ −8
Memory subtotal −15 (−20)
Error Er1 no structured path — 0
Er2 unchecked exceptions only ✅ −8
Er3 errors ignored/non-exhaustive — 0
Er4 no composable result type — 0
Error subtotal −8
Concurrency K1 GIL/no parallel — 0
K2 shared mutable state default — 0
K3 manual sync no race detection ✅ −8
K4 no structured concurrency — 0
K5 no primitives — 0
Concurrency subtotal −8
Platform P1 cannot function outside one vendor/domain — 0
P2 single-vendor but other uses — 0
P3 legacy/discontinued platform — 0
Platform subtotal 0

Core Dimensions score: 39/100 — total cost = −61 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension Mechanism Description Present Cost
Performance R1 interpreted no AOT/JIT ✅ −8
R2 GC pauses — 0
R3 JIT warmup — 0
Performance subtotal −8
Ecosystem Ec1 no package manager — 0
Ec2 fragmented tooling — 0
Ec3 small/niche/discontinued — 0
Ec4 proprietary ✅ −8
Ec5 platform-locked tooling — 0
Ec6 monoculture — 0
Ec7 legacy burden — 0
Ecosystem subtotal −8
Evolution V1 breaking changes — 0
V2 frozen — 0
V3 discontinued — 0
V4 glacial standards — 0
Evolution subtotal 0
Domain D1 domain/vendor lock-in ✅ −15
D2 poor domain fit — 0
D3 framework forces architecture — 0
Domain subtotal −15
Learning L1 steep ✅ −8
L2 large surface/multi-paradigm — 0
L3 sparse docs — 0
Learning subtotal −8
Syntax S1 verbose — 0
S2 inconsistent — 0
S3 punctuation-heavy — 0
Syntax subtotal 0
Testing G1 weak tooling — 0
G2 poor debugging — 0
G3 runtime-only errors — 0
Testing subtotal 0
Security Q1 memory-unsafe — 0
Q2 dynamic/weak typing risk — 0
Q3 known vulnerability/injection — 0
Security subtotal 0

Meta Dimensions score: 61/100 — total cost = −39 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension Mechanism Description Present Cost
Reproducibility Y1 build not reproducible ✅ −8
Y2 dependencies not pinned ✅ −8
Reproducibility subtotal −15 (−16)
Supply chain Y3 no signed provenance ✅ −8
Y4 registry without namespacing ✅ −4
Supply chain subtotal −12
Observability Y5 no stable tracing standard ✅ −8
Y6 no structured logging ✅ −4
Observability subtotal −12
Feedback Y7 slow build — 0
Y8 no fast in-editor analysis — 0
Feedback subtotal 0
Interop Y9 no foreign-function interface — 0
Y10 no portable target ✅ −4
Interop subtotal −4
Governance Y11 single-vendor governance ✅ −8
Y12 closed specification ✅ −8
Governance subtotal −15 (−16)

Readiness Dimensions score: 42/100 — total cost = −58 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: MATLAB’s design yields moderate language-imposed coupling for numerical engineering work. Matrix operations remove per-element iteration from the source, and toolboxes separate domain algorithms from the core language. Main strengths: an excellent fit for linear algebra, signal processing, and control systems; a large library; and a strong backward-compatibility record. Main weaknesses: the base workspace and every script variable form one shared mutable namespace with no namespaces, typing is dynamic with no static check, indexing is one-based against most languages, and the whole platform is proprietary, so cost and portability follow MathWorks’ licence and pricing.

The formal development. The definitions, theorems, and proofs behind this page are published in:

All published papers

References

[1]
Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.
[2]
Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.
[3]
Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.
[4]
MathWorks, “MATLAB documentation.” MathWorks, 2024. Available: https://www.mathworks.com/help/matlab/
[5]
R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.
[6]
N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.
[7]
S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.