Hacker News Reader

Comment by eberkund | Hacker News Reader

But do those things really contribute to the sophistication of the software? For example imagine some code written with no understanding of uranium enrichment:

    const int CENTRIFUGE_RPM = 500;

And then some other code written with a deep understanding of uranium enrichment:

    const int CENTRIFUGE_RPM = 1203;

Can you really say that the second bit of code is more "complex"? Same goes for stolen driver signing keys and some of the other things mentioned in the post.

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.

View on HN

>Can you really say that the second bit of code is more "complex"?

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...

agreed. upvoted.

Agreed. In computer science the smallest lever can move the largest mass and smaller levers are not inherently less sophisticated.

This is such a powerful distinction that I feel it should help us rethink language paradigms. Complexity is not (just) the complications one can impose by construct or the involutions required of ones algorithms, it's the overall real world system your code addresses.

Simple programs which are coded simply may address complex phenomena to complex ends--perhaps that's even the ideal?

Something something about simple rules being able to describe complex behaviour. Example: you can describe a flock of birds in motion around an object with 2 or 3 rules.

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.

That something something is actually Agent Based Modeling / Simulation.

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.

The problem with simple rules is the volume of computation. Theoretically you could write a tax code using quantum mechanics, but good luck calculating your tax each year (or before the heat death of the universe).

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.

Most people perceive complexity as things they don't understand. In that case, complexity will be relative.

> Most people perceive complexity as things they don't understand.

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 don't think difficulty is complexity. For example, the bitcoin mining protocol complexity is the same but the difficulty goes up or down.

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.

It seems you’re vastly misusing the words and their contexts here.

Complexity is difficulty of understanding. In the context of mathematical problems, that is the relevant kind of difficulty.

Sure, I suppose you'd just need a good definition for complexity. Notions like computational complexity have clear definitions while what I think you're describing might not. Or may be it would require some thinking and be valid in some limited regimes of "real world" effects as you call it.

You might enjoy Fred Brook's essay "No Silver Bullet", where he distinguishes between "Accidental Complexity" (basically, complexity created by software engineers when implementing a solution) and "Essential Complexity" (complexity that arises because software is written to solve some real world problem and the world is complex).

Stringing together independent pieces doesn't produce a significant rise in complexity.

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".

> const int CENTRIFUGE_RPM = 1203;

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

Most importantly it worked very successfully. With Windows, Google search, or most of the others mentioned here, they have had a huge number of problems. The word used was "sophisticated." I think that also implies some level of near-flawlessness in the end result.

... except it was discovered and widely publicized.

After it had dismantled a whole countries nuclear weapon program...

7 years after deployment

There is no telling. It could still be out there.

It was found, and now everyone is using that code base to iterate on new weapons.

99.99% of the time, Windows works just fine for me.

Stuxnet only needed to work once.

It worked multiple times. And it needed to propagate, undetected, for months until it made its way into the nuclear facility.

It didn’t just work once.

I think vkou might have been talking about the precision of Stuxnet.

The complexity or quality of a software code does not neccessarily say anything about the complexity of the problem it solves.

so true. upvoted

The sophistication of a piece of code is not merely an attribute of its complexity.

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)...

youre right. upvoted

There was a way to make your point politely and be taken seriously. This was not the way.

You mean the parent was being sarcastic? If so, it went over my head.

I think, the number of zero-days included in Stuxnet is an important factor in making it sophisticated and complex.

The second piece of code is not more complex, but it is (presumably) a lot more sophisticated.

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.

upvoted thanks

Typically, different words refer to different things. Most often, words considered synonyms actually refer to slightly different things.

From https://en.wikipedia.org/wiki/Sophistication

> 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.

The sophists, as you say, were ancient Greek teachers.

But sophistry now means something rather different: using subtle, specious reasoning to deceive.

Have you written motor control software before? If you haven't that might be why you can't tell. Whenever hardware is involved, with perhaps sometimes the exception of GPUs and workstation CPUs, I've noticed people's intuitions get a lot less reliable -- it's sort of like looking up the programming abstraction tower, lexical closures with higher-order functions to compute derivatives can seem awfully sophisticated to someone who's never seen something like it.

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)

Uh, that’s one small but important conponent of Stuxnet. The complexity is in the delivery mechanism, and the way it disguised itself, and the way it actually broke the centrifuges.

>Can you really say that the second bit of code is more "complex"?

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);
  }

Simple instructions, VERY complex code. Not as complex as this one, though, which took almost 20 years to come about:

  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);
  }

Chris Lomont says "The new constant 0x5f375a86 appears to perform slightly better than the original one. Since both are approximations, either works well in practice. I would like to find the original author if possible, and see if the method was derived or just guessed and tested."

A model aircraft can be simple, but an understanding of principles for designing it can be hard. IMHO, these two pieces of code are extremely simple, in terms of logic, instructions and computations. But they are sophisticated, the second is even more sophisticated than the first.

Root of the debate: words are not well-defined.

> But do those things really contribute to the sophistication of the software?

> Can you really say that the second bit of code is more "complex"?

I don't think you should equate complexity with sophistication.

I, personally, would differentiate between complex and sophisticated.

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.

yeah. in order to agree with that "most sophisticated software" claim i think he'd need to compare it to some other candidates for that title.

Hell, sure yes. The complexity is in the data. At the end of day, it is all 0s and 1s. It is the pattern/effect that matters.

Reply on news.ycombinator.com