4 ms·

> Python 3 fiasco Python 3 - fiasco or not - happened and went away. C++ fiasco is still ongoing with no end in sight - both on tooling side and language compl

by llukas 8y ago

> Python 3 fiasco Python 3 - fiasco or not - happened and went away. C++ fiasco is still ongoing with no end in sight - both on tooling side and language complexity side.

MaulingMonkey 8y ago
> Python 3 - fiasco or not - happened and went away. Bullshit. I'm still encountering actively maintained Python 2 codebases. Just to take one concrete example - Maya scripts, where AFAIK Python 3 still isn't an option. https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-3-x/idi-p/7963375 https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-... links http://www.vfxplatform.com/ http://www.vfxplatform.com/ which implies the Python 3 transition has been pushed back to 2020. Maybe it's gone for you. Great, I'm happy for you. I'm still dealing with the aftermath of not having a clean incremental upgrade path, so you can see why I'm not in favor of adding more? At work, we recently postponed a transition to C++17 due to library compatibility issues. Which is a shame - I'd really like to be using [[nodiscard]] for some APIs on MSVC (we're using vendor attributes on clang at least, but not everyone compiles with clang first.) I'm sure you understand, then, why I'm hesitant to make upgrading even harder.
- llukas 8y ago
  Python3 fixed issues with standard. In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. This has nothing to do with vendor refusing to upgrade.
  - MaulingMonkey 8y ago
    > In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. We agree there's a lot rotten with C++. I have a large list of complaints about C++ that's been growing for well over a decade now, but that's just what makes suggestions like this doubly frustrating. There's so much wrong with C++ that could be fixed, and non-issues with serious consequences to their "fixes" like "I can still use NULL" come up, distract and waste developer time (meaning less time can be spent on actual issues with real consequences), that suggest wasting even more time fixing what isn't broken. It's like some compulsion to make old code look new and shiny at all costs, even if s/NULL/nullptr/ is about as effective as putting lipstick on a pig in that regard. > This has nothing to do with vendor refusing to upgrade. I'm confused as to how an upgrade roadmap is "refusing to upgrade". You can see some of the minimum patch version bumps they've required in the tables I linked. Despite the fact that it's going to break things and leave downstream on older versions until they get a chance to make the upgrade. I've done the downstream fixes for Maya plugins before (D3D9 -> D3D11 for plugins that hook into the renderer), I'll probably end up doing the fixes for Maya python scripts broken by the 2 -> 3 upgrade whenever that lands too. The only way this is unrelated is if you live in a closed ecosystem where you have perfect control over your dependencies, no upstream or downstream to break compatability with, no branching to worry about, and a small or borderline inactive codebase where sweeping changes are trivial.

by llukas 8y ago

> Python 3 fiasco Python 3 - fiasco or not - happened and went away. C++ fiasco is still ongoing with no end in sight - both on tooling side and language complexity side.

MaulingMonkey 8y ago

> Python 3 - fiasco or not - happened and went away. Bullshit. I'm still encountering actively maintained Python 2 codebases. Just to take one concrete example - Maya scripts, where AFAIK Python 3 still isn't an option. https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-3-x/idi-p/7963375 https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-... links http://www.vfxplatform.com/ http://www.vfxplatform.com/ which implies the Python 3 transition has been pushed back to 2020. Maybe it's gone for you. Great, I'm happy for you. I'm still dealing with the aftermath of not having a clean incremental upgrade path, so you can see why I'm not in favor of adding more? At work, we recently postponed a transition to C++17 due to library compatibility issues. Which is a shame - I'd really like to be using [[nodiscard]] for some APIs on MSVC (we're using vendor attributes on clang at least, but not everyone compiles with clang first.) I'm sure you understand, then, why I'm hesitant to make upgrading even harder.

llukas 8y ago
Python3 fixed issues with standard. In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. This has nothing to do with vendor refusing to upgrade.
- MaulingMonkey 8y ago
  > In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. We agree there's a lot rotten with C++. I have a large list of complaints about C++ that's been growing for well over a decade now, but that's just what makes suggestions like this doubly frustrating. There's so much wrong with C++ that could be fixed, and non-issues with serious consequences to their "fixes" like "I can still use NULL" come up, distract and waste developer time (meaning less time can be spent on actual issues with real consequences), that suggest wasting even more time fixing what isn't broken. It's like some compulsion to make old code look new and shiny at all costs, even if s/NULL/nullptr/ is about as effective as putting lipstick on a pig in that regard. > This has nothing to do with vendor refusing to upgrade. I'm confused as to how an upgrade roadmap is "refusing to upgrade". You can see some of the minimum patch version bumps they've required in the tables I linked. Despite the fact that it's going to break things and leave downstream on older versions until they get a chance to make the upgrade. I've done the downstream fixes for Maya plugins before (D3D9 -> D3D11 for plugins that hook into the renderer), I'll probably end up doing the fixes for Maya python scripts broken by the 2 -> 3 upgrade whenever that lands too. The only way this is unrelated is if you live in a closed ecosystem where you have perfect control over your dependencies, no upstream or downstream to break compatability with, no branching to worry about, and a small or borderline inactive codebase where sweeping changes are trivial.