News for hackers. Stuff that matters.
Re:Do We Worship Complexity? by SilasX on Tuesday October 16, 2018 @05:23PM (#18233407)
It's unfair to dismiss that as sloppy slang; that's exactly what Big O notation exists for: to concisely express such concepts as "the number of classes increases linearly with the number of business requirements", as differentiated from "the number of classes is independent of business requirements" or "the number of classes increases with the square of business requirements".

The Orwell quote is valid at the heuristic level, but when

a) there's an installed base of people who know the jargon, and

b) the everyday English equivalent takes a lot more words to say the same thing, and

c) something coherent is meant by the jargon that could be so translated if necessary,

then that's exactly when you should use the jargon.

Give me "a^2 + b^2 = c^2" over "the sum of the squares of the lengths of a and b is equal to the square of the length of c".

Re:Do We Worship Complexity? by dfox on Tuesday October 16, 2018 @06:18PM (#18233782)
The point there is that Big-O notation also implies that the growth has given shape above some large-ish n. And metrics like "number of operators" or "number of bussiness requirements" rarely are so large that this makes sense.

And in fact approaches to system design that try to make the code size independent of number of bussiness requirements and their possible changes in future lead to exactly the kind of "complexity worship" discussed in TFA (various ad-hoc turing complete VMs that interpret code represented as rows in bunch of relational tables and what not).

Re:Do We Worship Complexity? by derefr on Tuesday October 16, 2018 @07:22PM (#18234163)
People who write "x is O(n)" usually actually mean to write "x ∝ n", but 1. ∝ is hard to type on a keyboard, and 2. even fewer people (including CS majors!) know what ∝ means, than know what O(n) means well-enough to allow them to figure out its non-jargon usage from context.
Re:Do We Worship Complexity? by SilasX on Tuesday October 16, 2018 @06:28PM (#18233845)
So you think that the imprecision of saying "O(n)" when the "large-ish" behavior is not relevant is worse than the verbosity of saying "scales directly/with the square of/not-at-all with [relevant constraint]"?

FWIW, Big-O itself, even in technical contexts, gets imprecise with e.g. calling hashtables O(1), which is not possible, even under the idealized computer model (instant memory access, etc).

Is there a shorter way of saying "scales proportionally with n" that you would suggest the tech community prefer because of its greater precision?

Re:Do We Worship Complexity? by twtw on Tuesday October 16, 2018 @06:39PM (#18233918)
But you can't just say "O(n)," you have to specify what n is - at which point it is no longer any more terse than the English alternative.

> What we ended up with was O(n) _classes_ (where n = the number of computation operations).

vs.

> what we ended up with was several classes for each operation.

The second is shorter, and says no more than what is relevant.

Re:Do We Worship Complexity? by SilasX on Tuesday October 16, 2018 @06:47PM (#18233955)
That's like saying there's no point in using pronouns, since you have to say the antecedent anyway.

It would be wrong in both cases because the context can make clear what a variable or pronoun refers to. If the problem context makes clear what the binding constraint is and you just need to talk about scaling behavior, then it is indeed shorter to say "O(1) rather than O(n)" vs "doesn't depend on the operations rather than being directly proportional".

>>what we ended up with was several classes for each operation.

>The second is shorter, and says no more than what is relevant.

It says less: the O notation is used to indicate that as you add more operations, you will need to add more classes, rather than only needing to add classes when there is logic the operations don't yet implement.

Re:Do We Worship Complexity? by TeMPOraL on Wednesday October 17, 2018 @02:40AM (#18236680)
Math doesn't define how big a "large-ish n" is. In casual usage, it may as well be n > 3, if the context suggests so.