[erlang-questions] Strings - deprecated functions

[Loïc Hoguin]

On 11/24/2017 07:39 PM, Eric des Courtis wrote:
> 
> 
> On Fri, Nov 24, 2017 at 9:40 AM, Loïc Hoguin <essen@REDACTED 
> <mailto:essen@REDACTED>> wrote:
> 
>     On 11/24/2017 03:07 PM, Eric des Courtis wrote:
> 
>           From my perspective, we want the following things:
> 
>            * The libraries to stay simple, small and clean (that means
>         throwing
>              away things)
>            * Our old code to continue to work without modifications
>         (that means
>              having a mechanism for compiling old code targetting new
>         versions of
>              Erlang)
> 
> 
>     That can work in many cases but not in the general case. This only
>     works for a specific set of changes where an equivalent still exists
>     in the code base.
> 
> That doesn't change the fact that most of the modules and functions we 
> are talking about don't have this problem. Therefore it is probably an 
> acceptable solution even if not perfect.

As far as OTP is concerned, this is not really the case. See 
https://github.com/erlang/otp/blob/master/lib/stdlib/src/otp_internal.erl

Outside OTP, the code doesn't change too much and when it does it's 
generally for very good reasons (a simple mapping wouldn't help).

>     For example removing ciphers or hashes in crypto requires human
>     intervention on every code bases that require them.
> 
> This is that is true and perhaps that is one of the few examples of 
> where it doesn't make sence to try to preserve good backwards 
> compatibility (assuming the app even knows about specific ciphers).
> 
> 
>     Another issue comes from old code requiring syntax or VM features
>     that have been removed.
> 
> It doesn't have to be all or nothing. As far as syntax goes we can 
> transpile the code.

Who's going to write the transpiler though? Better have OTP look toward 
the future than the past.

>     Then you have issues where it is technically still possible to do
>     the old functionality, but the performance or memory aspects are not
>     equivalent.
> 
> Again in most cases that isn't really an issue.
> 
> 
>            * To mix old and new Erlang code together
> 
> 
>     If it's maintained, no problem. If not, even if it compiles and runs
>     you should probably make sure to have a good set of tests to know it
>     still works as intended.
> 
> Even if libraries are old they usually come with tests so it can work 
> for many cases.
> 
> 
>     You'll want to do this even if OTP team go out of their way to make
>     sure everything stays compatible forever.
> 
> We are already more or less in that boat already.

That's pretty much my point. It doesn't really change things all that 
much. It's unclear whether the benefits outweight the efforts required.

>         I see no reason why we can't have both. What I am not okay with is:
> 
>            * Endlessly growing libraries of functions that are there for
>         legacy
>              reasons (wasting space and confusing new developers)
>            * Fixing libraries over and over again because something got
>         marked
>              deprecated
> 
>         So how do we get both? 
> 
>     You don't.
> 
> Yes but you can get something like 1.9 and reduce user pain substantially.
> 
> 
>     In fact your second point is incorrect: there's absolutely no reason
>     to fix a library because something got marked deprecated.
> 
> There is because it usually gets removed (so do the work now or later 
> what is the difference?). I don't always fix things until it's too late 
> and things don't work. And too be honest this stuff happens too often in 
> Erlang.

Well Fred's work around strings in rebar3 is a good example of where it 
does make a difference. Jumping through hoops to remove a warning when 
it could have easily been done a little before the functions were 
actually removed (but perhaps there was more value in this work than 
just the warning, I'm using it for the sake of an example).

You could also see things like this done by people when rand was 
released. Well, random is still around.

>     Zero.
> 
>     Developers should not "fix" libraries when something gets marked
>     deprecated. Developers should *take notice* that something has been
>     deprecated.
> 
>   If most deprecations never got removed I would agree however that 
> isn't my experience.
> 
> 
>     There's nothing to fix to begin with! Check your OCD levels and stop
>     trying to get rid of all the deprecation warnings with obscure parse
>     transforms or version-specific defines... 
> 
> That isn't really a big concern of mine.
> 
> 
>     The time to fix comes when the feature gets *removed* or is rendered
>     *incompatible*. (Or soon before that actually happens, anyway.)
> 
> Yes and I keep finding myself forking all kinds of libraries to fix this 
> crap. Often for no good reason at all.
> 
> 
>     As far as the string module is concerned, there's absolutely no need
>     to spend efforts to make your code run for both the old and the new
>     string module because the functions will not be removed for a very
>     long time. And until they are, chances are you will stop supporting
>     OTP versions before the new functions were introduced. You can do
>     the changes THEN.
> 
> Again it doesn't matter. You like doing changes last minute I don't. Now 
> that doesn't mean I am going to change 10 libraries in my application to 
> make sure they don't use tokens() or whatever. But when it gets removed 
> I get to waste time chasing functions that have been removed. Instead of 
> just marking it as OTP R16 compatible and moving on. The JVM solved this 
> a long time ago with the "-source" and "-target" option.

The JVM is a much better funded project with a lot more developers. It's 
hardly comparable.

It's ultimately a question of priorities. OTP team could slow down 
adding features or improvements that break things in subtle ways (zlib 
NIF, recently) and focus on making sure code written 5 or 10 years ago 
can still run without change. Is it worth it? I doubt it. Especially 
since a lot of this software will slowly become incompatible with 
security practices, new protocols, new operating systems, new hardware, 
and so on and so forth.

It's surely an interesting idea for the simpler cases, but it doesn't do 
much otherwise.

>     I am baffled every time someone opens a ticket telling me that I
>     have deprecation warnings. I know! But they're harmless and the code
>     works on all supported versions, so why would I spend efforts to
>     remove it?
> 
> You wont get that kind of issue from me.
> 
> 
>     Your question can be reframed to be about an endlessly growing
>     library + having to fix libraries when things get removed, which is
>     more of a choice, you can't really have both. Either you have an
>     endlessly growing library, or you remove functions and fix libraries
>     (manually or otherwise).
> 
> Yes that is what I meant to say (change deprecated to removed) .
> 
> 
> 
>     -- 
>     Loïc Hoguin
>     https://ninenines.eu
> 
> 

-- 
Loïc Hoguin
https://ninenines.eu