4 ms·

I was really looking forward to C++ ranges. However, that blog post by Eric Niebler felt like C++ ranges are trying to get everything right from a cs point of v

I was really looking forward to C++ ranges. However, that blog post by Eric Niebler felt like C++ ranges are trying to get everything right from a cs point of view, but in the process completely ignores usability / legibility, just like the previously introduced list operators that suffer from the requirement to specify start and end iterators. Some of the code samples are an atrocity. That C# example looks so much better to read and easier to understand.

munk-a 8y ago
I put a lot of value into the maintainability of what I'm writing and I think legible syntax is a language quality that's often minimized but provides a lot of value in terms of labour savings over the lifetime of a project. I've been working in PHP a bunch lately and the expressiveness there is amazingly strong, every time I go back to writing C++ it feels much more cargo-culty. (Also, PHP isn't perfect, but it's really good at allowing clear readable code, while also allowing terrible code, also the performance is terrible... Basically, don't waste your breath on why PHP is terrible - it isn't, it's a decent language - you're just using it wrong)
- zackmorris 8y ago
  I concur. My biggest gripe with C++ today is that it's conflating two concepts: imperative programming (IP) and functional programming (FP) via templates. Imperative programming has no future IMHO. Rust is going to the ends of the earth to make it "safe" but my gut feeling is that it will never be fully statically analyzable. Today I only see needless complexity that distracts from the underlying logic. I lost interest in this style of programming around a decade ago. Functional programming via templates is an admirable endeavor, and I went all the way to the ends of the earth to make something of it. I was left with code that wasn't reusable (wasn't salable) so in the end, just wasted years of my life on needless complexity. And both of the above only make sense from a performance perspective. An argument that becomes weaker with each passing year as processing speed improves. I think the future will be something more like reactive functional programming, written in a high level language like Javascript and only dropping down to bare metal optimizations with something like Rust when necessary. It will work like the UNIX shell (which is the only proven model that's endured). So something like the Actor model where a series of black boxes are wired together with pipes and as much FP as possible, and any IP sections are treated like monads and flagged as having unknown side effects. ClojureScript does something like this, running its FP code to completion and then yielding until more input/output happens on the Javascript side. Another way of thinking about this is a spreadsheet with some imperative code within the cells where needed. PHP is my favorite language currently because it has some notion of constness and fairly decent higher order functions (but who are we kidding, map and reduce give us everything else). PHP is a conceptually simple language that has some longstanding flaws with naming conventions that make it not as easy as it could be. It's largely succeeded in moving away from object-oriented programming, favoring a fairly simple interface implementation instead. I've never run into the implicit context problems that plague languages like Ruby (where convention over derivation is written into its DNA). And PHP is fairly fast, on the order of 200 times slower than C++ but probably within the same order of magnitude as the newer C++ methods mentioned in the article. My gut feeling is that proper string handling, with every contingency accounted for, runs approximately the same speed in any language. I'm not willing to spend time and effort trading safety for performance anymore.
  - blattimwind 8y ago
    > Another way of thinking about this is a spreadsheet with some imperative code within the cells where needed. Uhm, how are cell functions in spreadsheets an example of imperative programming?
    - zackmorris 8y ago
      Oh I was thinking of Visual Basic Excel macros, since VB is imperative. I'd like to see a spreadsheet that uses something like Elixer or Clojure though because then any cells that don't have monads could be fully statically analyzed and form a purely declarative solution. In other words, the cells could be decomposed further into cells containing individual functions instead of composed statements. That way the spreadsheet could be transpiled into lisp or a syntax tree. I'm using all these terms loosely, but they are equivalent.
- rrdharan 8y ago
  Also PHP7 addresses a lot of the performance issues, getting it up into the node.js range and ahead of Python 3 / Ruby in the microbenchmark wars at least: https://www.aerospike.com/blog/php7_php5/ https://www.aerospike.com/blog/php7_php5/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/php-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- yqh 8y ago
  If you think PHP is slow then you haven't used Python.
Tempest1981 8y ago
Yeah, I really appreciate Eric's ability to explain the feature. It really needs a tutorial like this, not just standard docs. That said, I think it's too complex for a portion of our team to grasp. So now what - do we use it, and alienate them? Or stay in the "dark ages"?

munk-a 8y ago

I put a lot of value into the maintainability of what I'm writing and I think legible syntax is a language quality that's often minimized but provides a lot of value in terms of labour savings over the lifetime of a project. I've been working in PHP a bunch lately and the expressiveness there is amazingly strong, every time I go back to writing C++ it feels much more cargo-culty. (Also, PHP isn't perfect, but it's really good at allowing clear readable code, while also allowing terrible code, also the performance is terrible... Basically, don't waste your breath on why PHP is terrible - it isn't, it's a decent language - you're just using it wrong)

zackmorris 8y ago
I concur. My biggest gripe with C++ today is that it's conflating two concepts: imperative programming (IP) and functional programming (FP) via templates. Imperative programming has no future IMHO. Rust is going to the ends of the earth to make it "safe" but my gut feeling is that it will never be fully statically analyzable. Today I only see needless complexity that distracts from the underlying logic. I lost interest in this style of programming around a decade ago. Functional programming via templates is an admirable endeavor, and I went all the way to the ends of the earth to make something of it. I was left with code that wasn't reusable (wasn't salable) so in the end, just wasted years of my life on needless complexity. And both of the above only make sense from a performance perspective. An argument that becomes weaker with each passing year as processing speed improves. I think the future will be something more like reactive functional programming, written in a high level language like Javascript and only dropping down to bare metal optimizations with something like Rust when necessary. It will work like the UNIX shell (which is the only proven model that's endured). So something like the Actor model where a series of black boxes are wired together with pipes and as much FP as possible, and any IP sections are treated like monads and flagged as having unknown side effects. ClojureScript does something like this, running its FP code to completion and then yielding until more input/output happens on the Javascript side. Another way of thinking about this is a spreadsheet with some imperative code within the cells where needed. PHP is my favorite language currently because it has some notion of constness and fairly decent higher order functions (but who are we kidding, map and reduce give us everything else). PHP is a conceptually simple language that has some longstanding flaws with naming conventions that make it not as easy as it could be. It's largely succeeded in moving away from object-oriented programming, favoring a fairly simple interface implementation instead. I've never run into the implicit context problems that plague languages like Ruby (where convention over derivation is written into its DNA). And PHP is fairly fast, on the order of 200 times slower than C++ but probably within the same order of magnitude as the newer C++ methods mentioned in the article. My gut feeling is that proper string handling, with every contingency accounted for, runs approximately the same speed in any language. I'm not willing to spend time and effort trading safety for performance anymore.
- blattimwind 8y ago
  > Another way of thinking about this is a spreadsheet with some imperative code within the cells where needed. Uhm, how are cell functions in spreadsheets an example of imperative programming?
  - zackmorris 8y ago
    Oh I was thinking of Visual Basic Excel macros, since VB is imperative. I'd like to see a spreadsheet that uses something like Elixer or Clojure though because then any cells that don't have monads could be fully statically analyzed and form a purely declarative solution. In other words, the cells could be decomposed further into cells containing individual functions instead of composed statements. That way the spreadsheet could be transpiled into lisp or a syntax tree. I'm using all these terms loosely, but they are equivalent.
rrdharan 8y ago
Also PHP7 addresses a lot of the performance issues, getting it up into the node.js range and ahead of Python 3 / Ruby in the microbenchmark wars at least: https://www.aerospike.com/blog/php7_php5/ https://www.aerospike.com/blog/php7_php5/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/php-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
yqh 8y ago
If you think PHP is slow then you haven't used Python.

Tempest1981 8y ago

Yeah, I really appreciate Eric's ability to explain the feature. It really needs a tutorial like this, not just standard docs. That said, I think it's too complex for a portion of our team to grasp. So now what - do we use it, and alienate them? Or stay in the "dark ages"?