5 ms·

>More features, more libraries, but is there a working group that looks back at C++98 and tries to reduce complexity by removing mistakes from the language? Th

by rl3 10y ago

>More features, more libraries, but is there a working group that looks back at C++98 and tries to reduce complexity by removing mistakes from the language? Then you break backwards compatibility. What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? Granted, reducing complexity does make the job of future compiler authors far less miserable.

ktRolster 10y ago
What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? I like that idea.
- koja86 10y ago
  You might find this project kind of interesting: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... As a day-to-day C++ practitioner I like it. ...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out. My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understanding. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++). And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list). EDIT: Removed the sir.
  - rl3 10y ago
    >Sir, ... You may want to take a quick gander at the profile of whom you're replying to. :) >... itching to give Rust a ride once it stabilizes just a bit more ... Likewise, though from my limited research it seems Rust has legacy baggage of its own already, and there's difficulty in coming to a consensus on what qualifies as idiomatic Rust. It seems that the same principle of cherry-picking a subset of features would apply just the same to Rust as it does to C++. The latter being far messier, of course.
    - koja86 10y ago
      Thank you in both cases sir/madam/whatever :-)
    - adelarsq 10y ago
      Some things still are on nightly builds, so will take some time to be perfect, at least for me. I have plans to use in production on next months =)
    - echelon 10y ago
      > it seems Rust has legacy baggage of its own already What is considered legacy cruft in Rust? The only change I'm aware of was the introduction of the `?` operator to replace the `try!` macro. That's easy to find/replace.
      - rl3 10y ago
        The notion extends to official libraries, not just the language itself. That said, I'm not the best person to ask, but cursory research turns up a few examples.[0][1][2][3] Some of these aren't examples of legacy cruft per se. However, as complexity is added to a language at a rapid rate, there becomes more confusion over what best practice actually is. [0] https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_idiomatic_rust_code_for_reference/ https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_... [1] https://users.rust-lang.org/t/rust-version-support-in-library-crates-best-practices/4405 https://users.rust-lang.org/t/rust-version-support-in-librar... [2] https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 [3] https://users.rust-lang.org/t/is-this-idiomatic-rust/2155 https://users.rust-lang.org/t/is-this-idiomatic-rust/2155

by rl3 10y ago

ktRolster 10y ago

What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? I like that idea.

koja86 10y ago
You might find this project kind of interesting: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... As a day-to-day C++ practitioner I like it. ...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out. My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understanding. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++). And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list). EDIT: Removed the sir.
- rl3 10y ago
  >Sir, ... You may want to take a quick gander at the profile of whom you're replying to. :) >... itching to give Rust a ride once it stabilizes just a bit more ... Likewise, though from my limited research it seems Rust has legacy baggage of its own already, and there's difficulty in coming to a consensus on what qualifies as idiomatic Rust. It seems that the same principle of cherry-picking a subset of features would apply just the same to Rust as it does to C++. The latter being far messier, of course.
  - koja86 10y ago
    Thank you in both cases sir/madam/whatever :-)
  - adelarsq 10y ago
    Some things still are on nightly builds, so will take some time to be perfect, at least for me. I have plans to use in production on next months =)
  - echelon 10y ago
    > it seems Rust has legacy baggage of its own already What is considered legacy cruft in Rust? The only change I'm aware of was the introduction of the `?` operator to replace the `try!` macro. That's easy to find/replace.
    - rl3 10y ago
      The notion extends to official libraries, not just the language itself. That said, I'm not the best person to ask, but cursory research turns up a few examples.[0][1][2][3] Some of these aren't examples of legacy cruft per se. However, as complexity is added to a language at a rapid rate, there becomes more confusion over what best practice actually is. [0] https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_idiomatic_rust_code_for_reference/ https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_... [1] https://users.rust-lang.org/t/rust-version-support-in-library-crates-best-practices/4405 https://users.rust-lang.org/t/rust-version-support-in-librar... [2] https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 [3] https://users.rust-lang.org/t/is-this-idiomatic-rust/2155 https://users.rust-lang.org/t/is-this-idiomatic-rust/2155