Here’s an amusing sentence I ran across this morning:
The code was simplified in 2003 and is harder to understand.
Maybe the author is being sarcastic, but I doubt it. I believe he means something like this:
In 2003, the code was made more concise. This made it simpler from the perspective of the maintainers of the code, sophisticated programmers well versed with the project. Unfortunately, this makes the code harder for novices, such as the intended audience for this book, to understand.
Quotation from An Introduction to Programming in Emacs Lisp.
See Simple versus easy for a discussion of what it means to be simple. We often conflate the two terms. Rich Hickey argues that ease is subjective but that simplicity can be objectively defined. He makes an interesting case, though his definition of simplicity may not be what people have in mind or want when they talk about simplicity.
I don’t have the context, but it sure sounds like sarcasm to me!
Similarly, on the flip side, complexity is not the same thing as being complicated. The Mandelbrot set is described by a formula of low complexity, but the generated fractal is immensely (infinitely) complicated. (viz Kolmogorov complexity)
I once had a colleague that made this distinction between complex and complicated — meant within the context of software design:
“Complex” can describe a system that has (perhaps necessarily) many parts with many interactions. There is nothing wrong with a complex solution when the problem domain is complex.
“Complicated” is a state that we have brought upon ourselves: taken something with few parts and few interactions and added moreto satisfy perceived edge cases or our own (over-)engineering sensibilities.