Efficiency is fundamentally at odds with elegance (2013)
1–10 of 46 posts
Re: Efficiency is fundamentally at odds with elegance (2013)
#2> Efficiency is fundamentally at odds with elegance
Strangely though their absence coincides in roughly 80% of all programmes, so "being at odds with" is meant as
(Efficiency -> NOT Elegance) AND (Elegance -> NOT Efficiency)
but not as
Elegance XOR Efficiency
Re: Efficiency is fundamentally at odds with elegance (2013)
#3I wouldn't say elegance here - there is something fundamentally elegant about the utilisation of 8-bit integers in scenarios where they can be used.
It is on the other hand, fundamentally at odds with accuracy - which is already well and widely known (at very least implicitly) and is the reason we so readily accept approximations in computing.
Re: Efficiency is fundamentally at odds with elegance (2013)
#4I've been writing firmware to run a DC motor controller where this efficiency/elegance tradeoff is very apparent. I can write "slower" code in a very elegant way, such as reading the throttle input. But when it comes to implementing the high-frequency control loop with all its ADC readings and filtering, I have to trade much of my elegance for raw efficiency.
Re: Efficiency is fundamentally at odds with elegance (2013)
#5I don’t think the author really addresses the examples presented.
The example of the FAST decision tree is based on a code generator, an abstraction which is presumably more elegant than the generated code which is littered with goto statements.
And what about std::sort? Say what you want about C++ in general, but it is definitely superior to a rudimentary qsort in C in terms of elegance and at least equivalent in terms of runtime efficiency.
There are plenty of examples in either direction. It would seem that this is yet another case of “it depends.”
Re: Efficiency is fundamentally at odds with elegance (2013)
#6Bad first example. Automatic differentiation in arbitrary precision is as elegant as symbolic, and as efficient as "floating point".
Re: Efficiency is fundamentally at odds with elegance (2013)
#7I would love to see the author revisit this today. What would they think of Rust, or the current state of C#, for instance?
Would F# or Nim be a much faster Python with less ugly C FFI?
Re: Efficiency is fundamentally at odds with elegance (2013)
#8There is a lot of truth to that, although I also see a third trade-off, which is robustness to change (not so much in the code but rather the inputs).
I think you can have in some cases efficiency and elegance, but then the solution will be either too abstract or specialized that it won't really be practical, and a small change in problem conditions will cause it not to work. (An example from the article - a matrix solver that only does a well-conditioned systems so the floating point errors never accumulate.)
Similarly, you can have robustness to change and elegance without efficiency (mathematically beautiful code), and robustness to change and efficiency without elegance (lot of copy pasting the code to deal with special cases).
In any case, I think we are generally trying to present elegant code to humans (using more abstract programming languages) and then use compilers to convert the elegance into efficiency. But it requires that somebody takes the pains to actually deal with all the possible cases (and write a working compiler).
Re: Efficiency is fundamentally at odds with elegance (2013)
#9Bad first example. Automatic differentiation in arbitrary precision is as elegant as symbolic, and as efficient as "floating point".
[deleted]
Re: Efficiency is fundamentally at odds with elegance (2013)
#10> Efficiency is fundamentally at odds with elegance Strangely though their absence coincides in roughly 80% of all programmes, so "being at odds with" is meant as (Efficiency -> NOT Elegance) AND (Elegance -> NOT Efficiency) but not as Elegance XOR Efficiency
What you are saying that there are a lot of programs that are neither elegant nor efficient. Few would dispute this, but I think this case is still covered by the original formulation.
For example I do not see "being drunk is fundamentally at odds with performing surgery" being invalidated by a bunch of folks writing programs in offices and fitting in neither bin. Caveat: I am not a native English speaker.