5 ms·

Whenever I read a post with this premise and the first thing that pops up is qsort, I instinctly call BS. (Sorry to the author, no offense meant, I didn't read

Whenever I read a post with this premise and the first thing that pops up is qsort, I instinctly call BS. (Sorry to the author, no offense meant, I didn't read the post). qsort is the prime example why (when!) generics do not matter. Half of the time if you need to sort, you're doing something wrong and the data should already be sorted (that's a sort in constant time). If that is not the case, but performance matters (which is quite unlikely by itself, since sorting is probably not where your program spends its time), then it is extremely likely that it's easy to write a much quicker sort than poort std::sort by taking advantage of the context. For example, some bucket sort which you could say runs in linear time. The time spent waiting for bloated C++ templates to compile can instead be used to implement a sort routine that beats std::sort for the specific situation, and to improve on it 12 times over. There is yet another point that is frequently heard, which is that compilers can inline function pointers if the "qsort" is defined as static inline. I'm only not sure how to guarantee that the inlining is performed. To me this goes mostly to show that most people that whine about generics & performance don't know a lot about performance.

vitno 4y ago
This comment really misses the point of the post and kinda just feels like you have an ax to grind about sorting. This feels like when people say "don't worry about memory safety, just don't write bad code". "don't worry about generics, just don't sort" Generic sorting is something all programmers are familiar with so it makes good examples.
- jstimpfle 4y ago
  It's not a good example if it isn't a realistic situation. Kinda like the Dog->Animal inheritance hierarchies to prove why OOP syntax is required.
  - ncmncm 4y ago
    OOP syntax is not in fact required, and such hierarchies are not in fact presented for that reason. They are used to illustrate a concept using a familiar subject. OOP is rarely the right way to organize a program, but almost any sufficiently large program has one or more subsystems that map naturally to OOP. A language that supports it is helpful in those places. Saying you could code the same thing without the feature wholly misses the point: of course you could, but it would be more work, and there would be more places to make mistakes. The same applies to any powerful language feature. Where it is useful, using it helps. Where it is not useful, another may be. Languages lacking powerful features make the programmer do more work, leaving less time and attention to make the program, or other more important programs, better.
    - jstimpfle 4y ago
      I wasn't saying there can't be a good way to put a feature to use. And, like any programmer that is maintaining a level of pride, I'm aware I am constantly looking for reasons why certain features aren't needed or are even bad in the global picture, at least in a given context. Looking for a minimal set of axioms to build the world on does make sense. Language feature can be seen as axioms in the sense that it's hard or impossible to break them down, since they're hidden in the compiler. Regarding OOP syntax specifically, let us agree that it is a question of religion if writing foo.bar() instead of foo_bar(foo) is really a huge saving of work. There are numerous counter-arguments (language-specific ones as well as more general ones) why it could be not, and could in fact be detrimental. I disagree with the view that using any feature to quickly get something done leaves more time to make the program better. In my view, less focus on syntactic superficialities like OOP method syntax, and premature optimizations like using std::sort, leaves more time to focus on what really matters, to understand what a program does and needs to do on a global scale, and it holds me back less waiting for slow builds. All of that is pretty subjective, and there are certainly good examples for many different approaches, and naturally one is most familiar with those that one likes personally. The important thing is to be happy and be / feel productive.
      - ncmncm 4y ago
        OOP is absolutely not about syntax. At all. The differing syntax is nothing but a visual clue, for benefit of readers, that some late binding might be going on. Literally anything that takes your attention necessarily takes it away from something else. Anything that does not need your attention anymore frees it up for important things you now have more time for. That is true for everyone, unless you waste it on looking at cat pictures (or, here) instead. Failure to understand the uses and consequences of unfamiliar language features is not a virtue. Every single line of code anyone writes does not use almost all features of a language. All that is different in your case is failure to use features in those places where using them correctly would have made your code better. The important thing is good code. If your code is not improving, you short-change yourself.
        4y ago
melissalobos 4y ago
> most people that whine about generics & performance don't know a lot about performance Really it is almost everyone who doesn't know a lot about performance. Any modern programming language is targeted not at an expert, but a beginner(look at Rust which is supposed to be relatively difficult, yet is quite quick for people to pick up in my experience). Languages should be able to be performant, even when used in poor ways. No matter what, people won't presort their data, since it likely comes from some database or csv file or json response or who knows what. So a language should be trying to accommodate that use case.
japhib 4y ago
You should probably read the post first, my dude. > Half of the time if you need to sort, you're doing something wrong and the data should already be sorted OP is literally talking about the C implementation of Postgres. He probably needs to sort.
- sophacles 4y ago
  Why can't postgres just get it's data in a pre-sorted way tho?
  - jstimpfle 4y ago
    Only the least technical among many possible reasons: it cannot know in advance the row ordering that is requested by the user.
  - sicp-enjoyer 4y ago
    Stable sort and binary search is the bread and butter of pretty much every database operation. When you bulk insert into indexed columns, it sorts the inserted data and merges that with the existing index. If you do joins on non-indexed columns it often sorts the intermediate results.
- jstimpfle 4y ago
  I hadn't known that we're on such close terms, my friend. Seems like this case is falling in the other half then.
  - jyounker 4y ago
    He knows the information about the author because he read the article.
  - japhib 4y ago
    If “my dude” offended you, I’m sorry. I was just trying to make it lighthearted. I get frustrated at the number of comments on HN articles that are mostly irrelevant if you’ve actually read the article.
sicp-enjoyer 4y ago
Sorting or hashing are the main ways to: - construct sets - remove duplicates - construct and query dictionaries (especially multi-maps, btrees, etc) - group equivalent elements - find the number of occurrences - etc Hashing solutions tend to be popular in modern language standard libraries, but not in C or C++ where in-place algorithms and simpler implementations are preferred. You could also make the argument that it's much harder to use hashes with generics as it's not always clear how to define good hashes for complex data types. Alternatively, sort requires only a < implementation. > bucket sort which you could say runs in linear time. This only works for integers in a small range. Also consider strings, doubles, or lexicographically ordered arrays.

vitno 4y ago

This comment really misses the point of the post and kinda just feels like you have an ax to grind about sorting. This feels like when people say "don't worry about memory safety, just don't write bad code". "don't worry about generics, just don't sort" Generic sorting is something all programmers are familiar with so it makes good examples.

jstimpfle 4y ago
It's not a good example if it isn't a realistic situation. Kinda like the Dog->Animal inheritance hierarchies to prove why OOP syntax is required.
- ncmncm 4y ago
  OOP syntax is not in fact required, and such hierarchies are not in fact presented for that reason. They are used to illustrate a concept using a familiar subject. OOP is rarely the right way to organize a program, but almost any sufficiently large program has one or more subsystems that map naturally to OOP. A language that supports it is helpful in those places. Saying you could code the same thing without the feature wholly misses the point: of course you could, but it would be more work, and there would be more places to make mistakes. The same applies to any powerful language feature. Where it is useful, using it helps. Where it is not useful, another may be. Languages lacking powerful features make the programmer do more work, leaving less time and attention to make the program, or other more important programs, better.
  - jstimpfle 4y ago
    I wasn't saying there can't be a good way to put a feature to use. And, like any programmer that is maintaining a level of pride, I'm aware I am constantly looking for reasons why certain features aren't needed or are even bad in the global picture, at least in a given context. Looking for a minimal set of axioms to build the world on does make sense. Language feature can be seen as axioms in the sense that it's hard or impossible to break them down, since they're hidden in the compiler. Regarding OOP syntax specifically, let us agree that it is a question of religion if writing foo.bar() instead of foo_bar(foo) is really a huge saving of work. There are numerous counter-arguments (language-specific ones as well as more general ones) why it could be not, and could in fact be detrimental. I disagree with the view that using any feature to quickly get something done leaves more time to make the program better. In my view, less focus on syntactic superficialities like OOP method syntax, and premature optimizations like using std::sort, leaves more time to focus on what really matters, to understand what a program does and needs to do on a global scale, and it holds me back less waiting for slow builds. All of that is pretty subjective, and there are certainly good examples for many different approaches, and naturally one is most familiar with those that one likes personally. The important thing is to be happy and be / feel productive.
    - ncmncm 4y ago
      OOP is absolutely not about syntax. At all. The differing syntax is nothing but a visual clue, for benefit of readers, that some late binding might be going on. Literally anything that takes your attention necessarily takes it away from something else. Anything that does not need your attention anymore frees it up for important things you now have more time for. That is true for everyone, unless you waste it on looking at cat pictures (or, here) instead. Failure to understand the uses and consequences of unfamiliar language features is not a virtue. Every single line of code anyone writes does not use almost all features of a language. All that is different in your case is failure to use features in those places where using them correctly would have made your code better. The important thing is good code. If your code is not improving, you short-change yourself.
      - 4y ago

melissalobos 4y ago

> most people that whine about generics & performance don't know a lot about performance Really it is almost everyone who doesn't know a lot about performance. Any modern programming language is targeted not at an expert, but a beginner(look at Rust which is supposed to be relatively difficult, yet is quite quick for people to pick up in my experience). Languages should be able to be performant, even when used in poor ways. No matter what, people won't presort their data, since it likely comes from some database or csv file or json response or who knows what. So a language should be trying to accommodate that use case.

japhib 4y ago

You should probably read the post first, my dude. > Half of the time if you need to sort, you're doing something wrong and the data should already be sorted OP is literally talking about the C implementation of Postgres. He probably needs to sort.

sophacles 4y ago
Why can't postgres just get it's data in a pre-sorted way tho?
- jstimpfle 4y ago
  Only the least technical among many possible reasons: it cannot know in advance the row ordering that is requested by the user.
- sicp-enjoyer 4y ago
  Stable sort and binary search is the bread and butter of pretty much every database operation. When you bulk insert into indexed columns, it sorts the inserted data and merges that with the existing index. If you do joins on non-indexed columns it often sorts the intermediate results.
jstimpfle 4y ago
I hadn't known that we're on such close terms, my friend. Seems like this case is falling in the other half then.
- jyounker 4y ago
  He knows the information about the author because he read the article.
- japhib 4y ago
  If “my dude” offended you, I’m sorry. I was just trying to make it lighthearted. I get frustrated at the number of comments on HN articles that are mostly irrelevant if you’ve actually read the article.

sicp-enjoyer 4y ago

Sorting or hashing are the main ways to: - construct sets - remove duplicates - construct and query dictionaries (especially multi-maps, btrees, etc) - group equivalent elements - find the number of occurrences - etc Hashing solutions tend to be popular in modern language standard libraries, but not in C or C++ where in-place algorithms and simpler implementations are preferred. You could also make the argument that it's much harder to use hashes with generics as it's not always clear how to define good hashes for complex data types. Alternatively, sort requires only a < implementation. > bucket sort which you could say runs in linear time. This only works for integers in a small range. Also consider strings, doubles, or lexicographically ordered arrays.