4 ms·

Actually, teaching people how to avoid inefficiencies might transform "slow code" to "slow and unmaintainable code". It's more strategic to teach people to wri

by Ace17 11y ago

Actually, teaching people how to avoid inefficiencies might transform "slow code" to "slow and unmaintainable code". It's more strategic to teach people to write readable code (exactly like the OP does), and then ... to teach them how to use a profiler.

jzwinck 11y ago
How is a profiler going to help if your code is riddled with inefficient structures? The "I in team" example can be made more efficient if SplitWords returns an iterator, but SplitWords itself won't be possible to change once it is ingrained in a codebase (because e.g. some call sites will come to depend on it returning a list). I love profilers as much as the next person, but if you build a system from inefficient building blocks, you may eventually need to build it again. But in a professional setting you are likely to be told not to do build it a second time, or you will be gone before that time comes, leaving someone else to clean up your moribund codebase of a thousand inefficiencies.
- dkersten 11y ago
  Make it work, then make it fast. I hear a lot of people complain about higher levels of abstraction in languages like C and C++, because they take away control or don't allow them to squeeze every last drop of performance out of their programs. I also see a lot of software in the wild that was programmed in C and C++ and runs very fast... but is buggy as hell or has pretty nasty security bugs. The fact is that, regardless how good you think you are, most likely you're not one of the few people who can write fast, bug-free[0] software in C and C++. I certainly am not despite having written quite a bit of C and C++ in the over the years. The amount of high-impact bugs (especially security bugs, eg Heartbleed) [0] Where I really mean: no severe bugs (data corruption, data loss, security flaws)
srean 11y ago
What you say is somewhat true most of the time when you are writing an application. However, when I am writing a library I have far less control over situations where functions in that library will get called. So it makes sense to make the library lean and lacking obvious bloats, or at least make efficient code paths possible without forcing the application programmer to indulge in excessive verbosity. This makes the library more broadly usable. As an application developer its a big pain to realize that the library that you have built your application around now needs to be incised out for performance reasons. In theory, if you design your interface well one can switch out libraries, but it is rarely as clean as what theory claims. Interfaces set, if not in stone, at least in in loose concrete, the data-structures that are convenient to use. EDIT: I hasten to add that I am not complaining about the library, far from it.
- dkersten 11y ago
  This: > it makes sense to make the library lean and lacking obvious bloats, or at least make efficient code paths possible without forcing the application programmer to indulge in excessive verbosity. Does not apply to these people: > It's hard enough teaching people to avoid inefficiency when it's right there in front of them, and harder still when you encapsulate inefficiency in a pretty package. who, by definition, are not experienced enough to write code that is sufficiently lean and lacking obvious bloat, or at least make efficient code paths possible. If they were, then they won't have a problem with the pretty package either.
  - srean 11y ago
    Just in the remote case you thought so, I am not the one you quoted in your second quote. I upvoted anyway.
    - dkersten 11y ago
      Oh, I know - it was from the post which you replied to. I only wanted to point out that in the context of the comment you replied to, I didn't feel that those were the people who should be worrying about optimised code.

by Ace17 11y ago

jzwinck 11y ago

How is a profiler going to help if your code is riddled with inefficient structures? The "I in team" example can be made more efficient if SplitWords returns an iterator, but SplitWords itself won't be possible to change once it is ingrained in a codebase (because e.g. some call sites will come to depend on it returning a list). I love profilers as much as the next person, but if you build a system from inefficient building blocks, you may eventually need to build it again. But in a professional setting you are likely to be told not to do build it a second time, or you will be gone before that time comes, leaving someone else to clean up your moribund codebase of a thousand inefficiencies.

dkersten 11y ago
Make it work, then make it fast. I hear a lot of people complain about higher levels of abstraction in languages like C and C++, because they take away control or don't allow them to squeeze every last drop of performance out of their programs. I also see a lot of software in the wild that was programmed in C and C++ and runs very fast... but is buggy as hell or has pretty nasty security bugs. The fact is that, regardless how good you think you are, most likely you're not one of the few people who can write fast, bug-free[0] software in C and C++. I certainly am not despite having written quite a bit of C and C++ in the over the years. The amount of high-impact bugs (especially security bugs, eg Heartbleed) [0] Where I really mean: no severe bugs (data corruption, data loss, security flaws)

srean 11y ago

What you say is somewhat true most of the time when you are writing an application. However, when I am writing a library I have far less control over situations where functions in that library will get called. So it makes sense to make the library lean and lacking obvious bloats, or at least make efficient code paths possible without forcing the application programmer to indulge in excessive verbosity. This makes the library more broadly usable. As an application developer its a big pain to realize that the library that you have built your application around now needs to be incised out for performance reasons. In theory, if you design your interface well one can switch out libraries, but it is rarely as clean as what theory claims. Interfaces set, if not in stone, at least in in loose concrete, the data-structures that are convenient to use. EDIT: I hasten to add that I am not complaining about the library, far from it.

dkersten 11y ago
This: > it makes sense to make the library lean and lacking obvious bloats, or at least make efficient code paths possible without forcing the application programmer to indulge in excessive verbosity. Does not apply to these people: > It's hard enough teaching people to avoid inefficiency when it's right there in front of them, and harder still when you encapsulate inefficiency in a pretty package. who, by definition, are not experienced enough to write code that is sufficiently lean and lacking obvious bloat, or at least make efficient code paths possible. If they were, then they won't have a problem with the pretty package either.
- srean 11y ago
  Just in the remote case you thought so, I am not the one you quoted in your second quote. I upvoted anyway.
  - dkersten 11y ago
    Oh, I know - it was from the post which you replied to. I only wanted to point out that in the context of the comment you replied to, I didn't feel that those were the people who should be worrying about optimised code.