> Without readability and comprehensibility, you cannot easily reuse your code.
Without reasonable efficiency, nobody would want to reuse your code. In fact, one of the hallmarks of reusable code is that it is efficient in a wide variety of circumstances; frequently the author of an API cannot predict what it will be used for, and thus must at the very least avoid pathological inefficiency when possible.
> I was not thinking about performance, about the efficiency of what I wrote, at all; I simply did not want to think about it at the time.
Bad software happens when you don't think about the efficiency of what you're writing at all. This perspective is completely detached from reality; in the real world, your code runs on a real machine and does real work. Sure, in some circumstances it's entirely appropriate to write inefficient code, but that's a decision that should be made after an assessment of the problem at hand. To intentionally ignore efficiency as a matter of policy is to ignore the facts of reality.
At the very least, you need to consider the performance impacts of the data structures you use. In most modern languages, it's not terribly difficult to use e.g. a hash in place of an array, and in the right circumstances it can make the difference between usable and unusable software. I can't even count how many tools I've used that, due to a poor choice of data structure, could not scale beyond the small data set that their authors tested them against, and were thus useless beyond a very limited scope.
I would argue that it depends on the developer. Someone just starting out and not having a great deal of experience with algorithms, data structures, security, and the like will need to spend much more time focusing on those aspects. Their challenge isn't [only] writing elegant, maintainable code... it's getting their code to work at all at a reasonable level of performance.
Someone who has been writing software for a few decades will be starting out having already implicitly rejected bad algorithms, unmaintainable designs, unscalable data structures, and poor security practices. Years of development has given them an intuitive feel for the best starting point for an efficient, scalable, and secure design.
Not to mention that anybody with sufficient experience knows to figure out the overall design first before cracking open the code editor. As such, their focus should be on keeping their code elegant and maintainable because it will be built on top of a reasonably performant architecture. And when they discover areas which need greater efficiency, the ease of refactoring the well designed architecture is an inherent bonus.
I agree with that. One thing I didn't mention in my original comment is that I think that there is often a rough correlation between elegant, readable code and at least basic efficiency. I tend to think that code that uses the right data structures looks cleaner. For instance, code using an array instead of a hash tends to look a little bit funny if it's constantly looking up elements by a particular attribute. This is especially the case today when so many excellent data structures and algorithms are already implemented in library code with nice pretty APIs. (I feel that I should mention, though, that the authors of those libraries probably worried a lot about efficiency!)
I tried to explain my position on the topic in such a way that we could have a conversation about it. Please, argue to the points I tried to make instead of slinging inflammatory remarks.
You're not discussing the topic, you're committing the logical fallacy of suggesting that the only alternative to your position is some absurd extreme. I.e. readable code is pathologically inefficient.
If you want to have a discussion, don't start by putting a ridiculous set of trousers on the straw-man you made.
I don't believe that my argument fell into the "false dichotomy" trap. The point I tried to make was that I don't think that there's ever a good point in the software development process where it makes sense to ignore performance altogether. I think that a holistic approach makes much more sense.
My argument was not a straw man. The original author specifically said that he, during a specific part of his development process, "[...] was not thinking about performance, about the efficiency of what I [he] wrote, at all [...]". I understand that he circled back on the performance issue later, but in my view, it makes more sense to start with an integrated performance/readability approach than to achieve both in multiple passes.
I was working out a prototype recently and we're turning it into production: it's falling down hard in the 'efficient' category, although it's really easy to read.
If I had thought about efficiency more when prototyping, I wouldn't have had to do the rework that is now looming.
Efficiency matters. Speed matters. Let's not delude ourselves that they don't.
OTOH, now that your prototype is deployed, you know what you need to make more efficient (and where the effort would be wasted instead), and if it's easy to read, it's hopefully also easy to modify.
Are you aware of how many outstanding web sites run on Rails? It might perform more poorly than other approaches, but in many circumstances that is a great trade-off for the power it gives the programmer.
Likewise with Python. There's a huge amount of successful software written in it. Anyway, as with Ruby, you can always drop down to C if you really need the efficiency.
Do you have any examples of why you consider Rails and Python to be "totally fucked"?
Without reasonable efficiency, nobody would want to reuse your code. In fact, one of the hallmarks of reusable code is that it is efficient in a wide variety of circumstances; frequently the author of an API cannot predict what it will be used for, and thus must at the very least avoid pathological inefficiency when possible.
> I was not thinking about performance, about the efficiency of what I wrote, at all; I simply did not want to think about it at the time.
Bad software happens when you don't think about the efficiency of what you're writing at all. This perspective is completely detached from reality; in the real world, your code runs on a real machine and does real work. Sure, in some circumstances it's entirely appropriate to write inefficient code, but that's a decision that should be made after an assessment of the problem at hand. To intentionally ignore efficiency as a matter of policy is to ignore the facts of reality.
At the very least, you need to consider the performance impacts of the data structures you use. In most modern languages, it's not terribly difficult to use e.g. a hash in place of an array, and in the right circumstances it can make the difference between usable and unusable software. I can't even count how many tools I've used that, due to a poor choice of data structure, could not scale beyond the small data set that their authors tested them against, and were thus useless beyond a very limited scope.