[erlang-questions] Strings - deprecated functions

[Joe Armstrong]

On Thu, Nov 23, 2017 at 9:39 PM, Michał Muskała <michal@REDACTED> wrote:
>
> On 23 Nov 2017, 17:35 +0100, Joe Armstrong <erlang@REDACTED>, wrote:
>
> I agree 100%
>
> If you make major changes to a library module that been around for a very
> long
> time you will break a lot of old code.
>
> At a first cast
>
> It's OK to add new functions to the module
> It's ok to fix bugs in old functions with changing the names
>
> But it NOT ok to remove functions or change the semantics of existing
> non-buggy functions.
>
> It's not as if we'll run out of module names soon. Call the new module
>
> strungs_v1 strings_1 or better_strings or strings_improved or
> anything you feel like but
>
>
> While this sounds great, I will argue that it's not very practical. The
> primary problem is that somebody has now to maintain both versions of the
> code.

Why maintain the old version?  As soon as there is a strings_v1 exist
then changes can be made there

> And there are situation when even old code needs to change - the
> particular case we're probably all agree with is when security issues are
> discovered.

Possibly - you could alwys issue a very strong compiler warning
"security problem in strings" please change to strings_v1


> If the team (which we assume is of fixed size) spends their time
> maintaining old code, they don't spend time developing new features.
> Resources are unfortunately limited.
>
> Another downside of keeping all old implementations is that it decreases
> readability of code. Code is read much more often than written and should be
> optimised for reading.

It should be but isn't - look at the history of erl_scan the first versions were
very readable - later versions were heavily optimised and far less readable

>  But now, each time I see strings:tokens/1 and
> strings_v1:tokens/1 I need to decide if they actually do the same when
> reading the code.

You could always write in strings_v1.erl

    tokens(X, Y) ->
         strings:tokens(X, Y).

and it would be abundantly clear - or use a  parse transform.


> And I need to do this every time I read the code. The same
> distinction is needed during an upgrade, but it's needed only once.

I still maintain that things with the same name must be the same.
As soon as you get two versions of strings offering different
functions then the name of the module 'strings.erl' becomes
ambiguous.

You have to say "I mean the version of strings in version 19.2 of Erlang"
Oh dear I thought you meant version 45.3"

If we use a name we should not have to qualify it by either the date
when the name was valid or by the checksum of the Git commit in which
it can be found.

Imagine what would happen if I could change my name on an arbitrary date

I was talking to joe the other day, when? 12 June 2015 - Oh you mean
when he was called
fred - No that was later he changed his name to Donald on the 23 th August 2016.

And what, is wrong with names like srings_vsn1, string_vsn_2 etc. it's
not as if the
integers are going to run out.


One thing I've always hated about revision control systems like GIT is
that the same name
means different things in different commits. This causes no end of
confusion and many errors.

Breaking peoples code by changing changing the libraries I view as a
fundamental sin.

After a few iterations you'll end up with two mutually incompatible
versions of a library
with the same name. One will export a with you want to use, the other
b which you also want to use.
But you cannot use both.

I have seen this in virtually every system I've every programmed.

Just invent a new name if you change things.

How difficult can that be?

/Joe


>
> Michał.