Yes.
Complexity in the sense discussed is related to the domain knowledge (including CS knowledge) required for the program to be written and work well.
Else even a trivial BS program could be very complex, just sprinkle it with gotos and unnecessarily convoluted code...
Simple programs which are coded simply may address complex phenomena to complex ends--perhaps that's even the ideal?
I don't think this is true. For example, as a math teacher, I couldn't do a very good job predicting how easy or difficult students would find particular problems. But I could easily predict which problems would be easier and which would be more difficult. I could do that even though I personally understood all the problems.
I'll attribute difficulty to the energy required to resolve a system. For example, pulling weight. The complexity of the action is the same. But the difficulty depends on the weights to pull.
Complex rules yields stupid results. Example: tax codes in most countries.
Must be a quote but I wasn't able to find a source for it.
When systems get too complex to simulate from first principles, we have to resort to inductive reasoning--observe the system and then create rules as we see a need.
Yes the resulting rule set is a mess, like our tax code. But the physical system that the U.S. federal tax code (for example) covers--the United States of America--is mind-bogglingly complex.
We have trouble computationally simulating more than a certain number of neurons... there are billions of neurons in each human brain, and there are hundreds of millions of human brains interacting in the U.S. This does not even get into other physical phenomena like surface water or mineral distribution.
The results are stupid because we are too stupid to understand and analyze the system we're trying to describe and manage.
Back when I was in academia I used to develop ABMs to represent the behaviour of complex systems with a simple set of rules of agent action and interaction.
The game of Life is the quintessential example of that.
For instance, the payload which specifically looks for uranium centrifuge hardware is independent of the worm which carries the payload. They can be developed separately, by different people, and combined.
That specific worm could carry a payload to attack anything.
Or, that specific payload could be carried by any worm.
There is next to no coupling between "worm" and "payload".
As the linked article points out, it wasn't just raising the speed, it was raising it in a subtle enough way to ruin the process while other experts routinely monitored the system
Stuxnet only needed to work once.
It didn’t just work once.
Else a program with tons of accidental complexity (a badly written program by an intern) would be equally good with a program with huge essential complexity (a 10 line program that takes tons of domain and/or programming knowledge to write)...
The fact that I had to prefix that with "(presumably)"—i.e. I can't actually tell using my own expertise—is evidence of that.
Of course if the sophistication is more about what they needed to know in order to break the things (and make that code change), then talking about this subsystem by itself that's either way lower or roughly the same as what they'd need to know to build and operate their own centrifuges. Much less, if they only needed to focus on one part of the process (motor control) that would cause problems (which might just be a brief consultant call with our own nuclear physicists and engineers, I don't know, nuclear science details seem as mysterious to me as high level language details might to impoverished programmers), or about the same, if they knew everything the Iranians knew about the systems (did we ever find out if they got all the blueprints and so forth and built replicas for end-to-end testing?) plus a bit extra on how and where to make it break without easily being detected.
Anyway how sophisticated can they really be when they didn't even use source control? (Old joke... https://news.ycombinator.com/item?id=4052597)
> Sophistication has come to mean a few things, but its original definition was "to denature, or simplify". Today it is common as a measure of refinement
So no, it can in many cases even be the precise opposite of complexity.
It actually originally comes from "sophistry", which is an ancient greek discipline of wisdom and excellence. I would generally associate the word with a high level of complexity that has been expertly reduced and refined to an elegant quality.
But sophistry now means something rather different: using subtle, specious reasoning to deceive.
Yes. Take fastinvsqrt() for example. Cleve Moler learned about this trick from code written by William Kahan and K.C. Ng at Berkeley around 1986.
float fastInvSqrt(float x) {
int i = *(int*)&x;
i = 0x5f3759df - (i >> 1);
float y = *(float*)&i;
return y * (1.5F - 0.5F * x * y * y);
}
float fastInvSqrt(float x) {
int i = *(int*)&x;
i = 0x5f375a86 - (i >> 1);
float y = *(float*)&i;
return y * (1.5F - 0.5F * x * y * y);
}
Root of the debate: words are not well-defined.
> Can you really say that the second bit of code is more "complex"?
I don't think you should equate complexity with sophistication.
That is just one line of code, sure. But I can't imagine what it took to get that line of code there, and everything that comes with that. How many people were involved, PhD's, years of experience in a range of fields, and not just years of experience in any field but experience in fields like espionage.
My uneducated brain would still put "most sophisticated software ever written" in the hyperbole box, but even then I'm hesitating.
Other large software projects like operating systems or Google search involve much more complex software concepts which I think is the primary thing that should be measured when discussing the sophistication of software.