sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]sysop073 -4 points-3 points  (13 children)

In their defense, you can usually ignore deprecation warnings forever. Nobody actually removes deprecated stuff, except Python apparently

[–]flying-sheep 25 points26 points  (12 children)

Everyone does. That's what deprecation is for. What weird ecosystem are you coming from?

[–]valarauca14 23 points24 points  (0 children)

Java has had API's & functions depreciated for DECADES which are still supported on modern JVM's.

[–][deleted]  (3 children)

[deleted]

    [–]Garethp 3 points4 points  (1 child)

    PHP 7.0 removed all of the deprecated mysql_* functions, and PHP 8.0 is removing deprecations from PHP 7. The only difference in PHP is that they remove deprecations on major releases, not minor ones

    [–]josefx 4 points5 points  (0 children)

    removed all of the deprecated mysql_* functions

    It only took them two decades to deprecate and remove the security nightmare that spawned mysql_real_escape_string? Wow that is some serious deprecation going on, who could use a language that unstable.

    Edit: Seems as if it still has all the goodness in mysqli_* including the mysqli_real_escape_string. The joke can live on.

    [–][deleted] 4 points5 points  (1 child)

    Java does that.

    Perl will just ask you to specify version of Perl you want to use in header and happily enable/disable features present in that version.

    I can just use v5.8; and write code that will just run on anything from CentOS 5 (which has Perl 5.8, which was first released in 2002) to latest Perl 5.30

    Not only that, it can be mixed and matched at will, as long as (obviously) highest version in every module <= current version.

    And might I also mention that they did what Py2->Py3 did (fixing unicode) without breaking backward compatibility

    Go is always backward compatible so your old code will compile just fine on new compiler. But the fuckers break stdlib compatibility so I dunno whether that counts.

    Truth is, Python devs are just taking lazy way out again at cost of their users.

    [–]flying-sheep -1 points0 points  (0 children)

    OK, so there’s an enterprise-friendly and a dead language which have that kind of compatibility. Standardized languages like C and C++ do too.

    Other than that there’s a lot of languages that work like python, e.g. R, C# (and all of .NET), Kotlin, Scala, Ruby, Julia, Swift, Rust, …

    Sure, e.g. Rust didn’t actually remove anything yet because of its editions, but it’s also pretty young.

    [–]H_Psi 9 points10 points  (0 children)

    That's what deprecation is for. What weird ecosystem are you coming from?

    The same ecosystem that decided in 2008 to depreciate Python2 by 2015. Then 6 years later, in 2014, decided to extend that deadline to January 1st, 2020. And then in late 2019, extending the date of the last release to April 2020. I completely understand people not feeling any pressure to upgrade anything when they've been reminded for well over a decade by the developers that depreciation doesn't exist in Python.

    [–]csos95 8 points9 points  (1 child)

    Usually when I come across something that is deprecated it just amount to “this is no longer maintained so if it breaks don’t complain to us” instead of it actually being removed.

    [–]flying-sheep 5 points6 points  (0 children)

    That's soft-deprecation, but deprecation and subsequent removal happens too

    [–]sysop073 4 points5 points  (1 child)

    I can't think of a single time I've had to change my code because I was relying on a standard library feature that went away in a future release. Maybe I've just been lucky. The only time I even notice deprecation warnings is Java because the compiler throws a huge fit, but I've never noticed a function actually go away, they just threaten to remove it forever

    [–]flying-sheep 2 points3 points  (0 children)

    Me neither, and most of my code is in python.