Strings - deprecated functions

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Eric des Courtis-3
While I feel the pain of Joe having suffered countless hours fixing deprecation in various old libraries. I have to say there is something to be said for throwing things away.

I can't help but think I can have my cake and eat it too. Maybe something like a transpiler to compile old Erlang to new Erland and keep the Erlang VM lean?

On Thu, Nov 23, 2017 at 5:35 PM, Éric Pailleau <[hidden email]> wrote:
Hi,

If Erlang had namespaces we could imagine old strings function if no namespace,  for old code compat, while new code could use same functions names, but with a namespace. Let say -namespace(strings, pref1, "http://www.erlang.org/strings/utf8"). In header.

When using functions with mixed namespaces,  Use of a prefix would solve the problem. 

pref1::strings:func() for new utf8 module or strings:func() for legacy latin1 ones.

This would also solve the very complicated problem of module name clashes from different repositories...

Regards 


Le 23 nov. 2017 11:00 PM, Joe Armstrong <[hidden email]> a écrit :

On Thu, Nov 23, 2017 at 9:39 PM, Michał Muskała <[hidden email]> wrote:
>
> On 23 Nov 2017, 17:35 +0100, Joe Armstrong <[hidden email]>, 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ł.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

zxq9-2
On 2017年11月24日 金曜日 08:13:49 Eric des Courtis wrote:
> While I feel the pain of Joe having suffered countless hours fixing
> deprecation in various old libraries. I have to say there is something to
> be said for throwing things away.
>
> I can't help but think I can have my cake and eat it too. Maybe something
> like a transpiler to compile old Erlang to new Erland and keep the Erlang
> VM lean?

If the new functions did what the old functions do, then sure.

But that's not how thing have turned out.

On reflection, I actually think the new string functions should have
been rolled into a "utf8" module. Or something. And the "strings" module
could either have had implementation adjustments that use the utf8
utilities underneath or been left alone to deal with latin1 (but either
way be amply documented).

I'm the heaviest unicode string dealing guy I know. I'm SUPER happy that
the idea of "string" has been advanced (finally!) to mean "unicode strings".
But breakage is a thing, and Lloyd and Joe have a point.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Loïc Hoguin-3
On 11/24/2017 02:37 PM, zxq9 wrote:

> On 2017年11月24日 金曜日 08:13:49 Eric des Courtis wrote:
>> While I feel the pain of Joe having suffered countless hours fixing
>> deprecation in various old libraries. I have to say there is something to
>> be said for throwing things away.
>>
>> I can't help but think I can have my cake and eat it too. Maybe something
>> like a transpiler to compile old Erlang to new Erland and keep the Erlang
>> VM lean?
>
> If the new functions did what the old functions do, then sure.
>
> But that's not how thing have turned out.
>
> On reflection, I actually think the new string functions should have
> been rolled into a "utf8" module. Or something. And the "strings" module
> could either have had implementation adjustments that use the utf8
> utilities underneath or been left alone to deal with latin1 (but either
> way be amply documented).
>
> I'm the heaviest unicode string dealing guy I know. I'm SUPER happy that
> the idea of "string" has been advanced (finally!) to mean "unicode strings".
> But breakage is a thing, and Lloyd and Joe have a point.

Nothing has been broken as far as I understand. I'm not sure what's the
big deal. New set of functions has been added, old set of functions
still works the same, still documented but will very slowly be rolled out.

Joe's ideals are very much unrealistic, it's very unlikely that
computers work the same in 1000 years, it's very unlikely that Erlang is
still around then, that anyone remembers the programs we wrote today or
heck even that our civilizations still exist. The odds are not much
greater for 100 years in the future as far as the code goes. The problem
is much more practical, and one practical aspect to think about is
maintenance. Old code has to be removed eventually to lower the
maintenance costs (for OTP team). Still, I doubt this particular code
will be removed in the next 10 years. I'd bet something like gen_fsm
would be removed far quicker than the old string functions.

Lloyd's issues seem to be more about documentation, specifically it
lacking examples for converting to the new functions. This kind of issue
will be resolved long before the old functions are removed.

OTP has slowly phased out a lot of code. It's nothing new. This time
it's both a combination of this and the world phasing out latin1, so
that's more reasons to move forward.

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Eric des Courtis-3
In reply to this post by zxq9-2
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)
  • To mix old and new Erlang code together
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?

On Fri, Nov 24, 2017 at 8:37 AM, zxq9 <[hidden email]> wrote:
On 2017年11月24日 金曜日 08:13:49 Eric des Courtis wrote:
> While I feel the pain of Joe having suffered countless hours fixing
> deprecation in various old libraries. I have to say there is something to
> be said for throwing things away.
>
> I can't help but think I can have my cake and eat it too. Maybe something
> like a transpiler to compile old Erlang to new Erland and keep the Erlang
> VM lean?

If the new functions did what the old functions do, then sure.

But that's not how thing have turned out.

On reflection, I actually think the new string functions should have
been rolled into a "utf8" module. Or something. And the "strings" module
could either have had implementation adjustments that use the utf8
utilities underneath or been left alone to deal with latin1 (but either
way be amply documented).

I'm the heaviest unicode string dealing guy I know. I'm SUPER happy that
the idea of "string" has been advanced (finally!) to mean "unicode strings".
But breakage is a thing, and Lloyd and Joe have a point.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

zxq9-2
On 2017年11月24日 金曜日 09:07:11 you wrote:
> So how do we get both?

The eternal million-dollar-question.

My (probably crappy) solution is the same for this as for untangling
dependency knots:

semver + static dependency declarations

This also means no automatic dependency upgrades.

I'm not sure how to make this a part of Erlang itself, though, so for now
my way of doing things involves making it possible to execute different
ERTS versions and making each execution of a program determine from its
metadata what specific libs to pull, build and include in the execution
environment (that is, do not allow "latest available", instead be explicit).

...which means, of course an external tool that does all that, and a repo
that knows what you are asking for. It is up to a packager to define explicit
dependencies (but dependencies are flat declarations, not trees that might
conflict -- working that out is the packager's main burden, and this means
you get bug-reproducible re-runs within a specific version of a package).

I've never attempted to make a cross-platform utility that could install
various versions of Erlang on the fly (Windows is always a mystery) but
a cheap way of leaning on kerl has worked for me in the past on Linux.
But again, it requires extra declarations on the part of a packager, which
means someone has to test on various versions. This rarely happens, so I
cheat and tend to wind up always just writing against the latest ERTS
release -- and then we run into the core lib changes problem again.

Anyway, its a circle of fun. Runtime and stdlib changes are always white
hot with friction.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Loïc Hoguin-3
In reply to this post by Eric des Courtis-3
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.

For example removing ciphers or hashes in crypto requires human
intervention on every code bases that require them.

Another issue comes from old code requiring syntax or VM features that
have been removed.

Then you have issues where it is technically still possible to do the
old functionality, but the performance or memory aspects are not equivalent.

>   * 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.

You'll want to do this even if OTP team go out of their way to make sure
everything stays compatible forever.

> 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.

In fact your second point is incorrect: there's absolutely no reason to
fix a library because something got marked deprecated.

Zero.

Developers should not "fix" libraries when something gets marked
deprecated. Developers should *take notice* that something has been
deprecated.

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...

The time to fix comes when the feature gets *removed* or is rendered
*incompatible*. (Or soon before that actually happens, anyway.)

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.

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?

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).

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Joe Armstrong-2
On Fri, Nov 24, 2017 at 3:40 PM, Loïc Hoguin <[hidden email]> 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.
>
> For example removing ciphers or hashes in crypto requires human intervention
> on every code bases that require them.
>
> Another issue comes from old code requiring syntax or VM features that have
> been removed.
>
> Then you have issues where it is technically still possible to do the old
> functionality, but the performance or memory aspects are not equivalent.
>
>>   * 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.
>
> You'll want to do this even if OTP team go out of their way to make sure
> everything stays compatible forever.
>
>> 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.
>
> In fact your second point is incorrect: there's absolutely no reason to fix
> a library because something got marked deprecated.
>
> Zero.
>
> Developers should not "fix" libraries when something gets marked deprecated.
> Developers should *take notice* that something has been deprecated.
>
> 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...
>
> The time to fix comes when the feature gets *removed* or is rendered
> *incompatible*. (Or soon before that actually happens, anyway.)
>
> 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.
>
> 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?
>
> 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).

You are quite right - what I'd like is a garbage collector for code.
Given a root query  and a set of modules remove all code that can
never be reached.

Actually the way Knuth did things was pretty good TeX provides
a great example.

The version numbers were the digits of Pi
TeX is currently at version 3.14159265

Knuth offered a reward of $2.56 for the first error in TeX to be
doubled for each new error
reported.

TeX was implemented as an initial program, followed by a set of patch files)
to get to version you take the first version then apply a set of
patches to get to the
version you want.

We could do this in erlang - some syntax like:

    -module(string)
    -vsn(10)
    -remove([func1/4, func4/3]).

    func7() ->
          ....

    etc.

This might create a module called string_10.erl and would be a copy of
all the code in string_9.erl
the remove declaration just removes code from string_9.erl

Any additional functions in the module are just added to the new module.

This way the old and new code could happily co-exist.

For developers there could be a "window" of code they might maintain say from
string_7 to string_10 and this would migrate forwards with time,

This scheme worked well for Knuth but assumes a single thread of
development with
no branches.

Cheers

/Joe









>
> --
> Loïc Hoguin
> https://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

bengt e
In reply to this post by Eric des Courtis-3
Greetings,

Would something like 'go fix' be possible for Erlang, in this particular case?


bengt

On Fri, Nov 24, 2017 at 3:07 PM, Eric des Courtis <[hidden email]> 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)
  • To mix old and new Erlang code together
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?

On Fri, Nov 24, 2017 at 8:37 AM, zxq9 <[hidden email]> wrote:
On 2017年11月24日 金曜日 08:13:49 Eric des Courtis wrote:
> While I feel the pain of Joe having suffered countless hours fixing
> deprecation in various old libraries. I have to say there is something to
> be said for throwing things away.
>
> I can't help but think I can have my cake and eat it too. Maybe something
> like a transpiler to compile old Erlang to new Erland and keep the Erlang
> VM lean?

If the new functions did what the old functions do, then sure.

But that's not how thing have turned out.

On reflection, I actually think the new string functions should have
been rolled into a "utf8" module. Or something. And the "strings" module
could either have had implementation adjustments that use the utf8
utilities underneath or been left alone to deal with latin1 (but either
way be amply documented).

I'm the heaviest unicode string dealing guy I know. I'm SUPER happy that
the idea of "string" has been advanced (finally!) to mean "unicode strings".
But breakage is a thing, and Lloyd and Joe have a point.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Fred Hebert-2
On 11/24, bengt e wrote:
>Greetings,
>
>Would something like 'go fix' be possible for Erlang, in this particular
>case?
>

Not really. Functions like string:chr return a position of a matching
character. There is no telling what that position will be used for later
on.

Another example is the ssl_verify_fun library. That one does hostname
validation for SSL certificates. Replacing string functions working on
ASCII/latin-1/ISO-8859-1 by unicode-aware strings that do normalization
and whatnot is actually a potential security risk.

Those are not entirely equivalent problem domains, and not all strings
are equivalent in all contexts and encodings.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Fred Hebert-2
In reply to this post by zxq9-2
On 11/24, zxq9 wrote:
>On 2017年11月24日 金曜日 08:13:49 Eric des Courtis wrote:
>On reflection, I actually think the new string functions should have
>been rolled into a "utf8" module. Or something. And the "strings" module
>could either have had implementation adjustments that use the utf8
>utilities underneath or been left alone to deal with latin1 (but either
>way be amply documented).
>

This would be bad naming; utf8 is but one encoding of Unicode as I'm
sure you're aware. The current string module should be able to handle
utf8, utf16, utf32, *and* lists of codepoints (chardata()).

'strings' is sadly the most appropriate name for this module, and for
the first time it also has the ability to really handle *anything* we
consider to be a string: lists, binaries, and mixes of both.

The problem was really that the old 'string' module was not super great
at being a 'string' module. It would have been better named as 'cstring'
or something.

Maybe it could have been 'str' instead, who knows. Then we'd get cool
conference talks saying how shitty and confusing the stdlib is because
you don't know whether to use string or str in your code!

Please let's not get inspired by 'mysql_real_escape_string', which had
to be implemented because 'mysql_escape_string' was not good enough but
people kept relying on it. It's a laughing stock and even a security
problem for everyone in that case.

>I'm the heaviest unicode string dealing guy I know. I'm SUPER happy that
>the idea of "string" has been advanced (finally!) to mean "unicode strings".
>But breakage is a thing, and Lloyd and Joe have a point.
>

I think we have to consider a thing, as someone else has mentioned: old
code is not broken. Old code keeps running. Old code is fine. It has a
new compiler warning.

Old code could be wrong, because it may be getting unicode data and
mangling it instead of doing the right thing. Old code could not even
detect that. Old code was getting passed by everyone in the world. Old
code can't even work safely on Erlang modules or the content of your
.app file anymore because that content is now UTF-8.

We can't know. For all we care, old code is getting to break because the
world is passing it by and it's not keeping up. If old code must remain
stable in a changing world, old code must be run in its old context:
maybe stick it into the same old VM, or vendor it in along with its
build tools, artifacts, and everything it needs (be careful though, R15
old code no longer can fetch packages or dependencies safely, since TLS
from R15 is no longer safe in the real world).

Old code can't necessarily be recompiled onto new tools, because new
tools have to address a changing world. Sad thing for old code, but if
you use old tools, maybe it will work.

Maybe one can just copy/paste the string.erl module into cstring.erl,
change the `-module` attribute, and then do a 'sed' call on their code.  

If old code is expected to work together with the existing API and no
changes, but that the API is no longer right for the current world,
maybe old code should freeze its dependencies and environment.

In any case, current code is not yet old code. It's being told that
eventually it will be old code. In the meanwhile, people who need to
worry are those who need to support more than one version at once. Those
people feel some pain for sure. The other people to suffer are those on
a tight budget with humongous codebase whose life may be to keep
maintaining changing code all the time because there's so much code they
can hardly keep up with all the changes.

So uh, what are you gonna promise in terms of breaking? It sounds like
the best policy is to pick a value of what you promise in terms of
backwards compatibility, and the OTP team has a very clear policy there.  
Two major versions at least.

The risk of never changing nor breaking a thing forever is that old code
can prevent new code from being written if old code is so bad that new
code can't make sense.  Then you have nothing but old code. You've
accrued enough technical debt that nobody who hasn't grown with the
system can now understand it. Then your old code for your old system is
only possible to be used and maintain by old programmers, because the
new programmers have gone somewhere else.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Eric des Courtis-3
In reply to this post by Loïc Hoguin-3


On Fri, Nov 24, 2017 at 9:40 AM, Loïc Hoguin <[hidden email]> 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.

For example removing ciphers or hashes in crypto requires human intervention on every code bases that require them.

Another issue comes from old code requiring syntax or VM features that have been removed.

Then you have issues where it is technically still possible to do the old functionality, but the performance or memory aspects are not equivalent.

  * 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.

You'll want to do this even if OTP team go out of their way to make sure everything stays compatible forever.

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.

In fact your second point is incorrect: there's absolutely no reason to fix a library because something got marked deprecated.

Zero.

Developers should not "fix" libraries when something gets marked deprecated. Developers should *take notice* that something has been deprecated.

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...

The time to fix comes when the feature gets *removed* or is rendered *incompatible*. (Or soon before that actually happens, anyway.)

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.

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?

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).
That is what I meant. 


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


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Eric des Courtis-3
In reply to this post by Loïc Hoguin-3


On Fri, Nov 24, 2017 at 9:40 AM, Loïc Hoguin <[hidden email]> 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.

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. 

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. 

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. 

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.

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


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Loïc Hoguin-3
On 11/24/2017 07:39 PM, Eric des Courtis wrote:

>
>
> On Fri, Nov 24, 2017 at 9:40 AM, Loïc Hoguin <[hidden email]
> <mailto:[hidden email]>> 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
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Richard A. O'Keefe-2
A couple of years ago I was working through a Java book.
Not one of the examples got a clean compile.  Not one.
oddly enough, it was string-handling functions that had
been deprecated, and oddly enough, in my environment the
old functions still did everything I needed.

It's not just Erlang and Java.  I had C code using some of
the classic string functions in ways I had carefully ensured
were correct.  Porting to the next version of the Unix
flavour I was using, the linker screamed at me about unsafe
functions.  Since I wanted other people to use the program
and didn't want them looking down on me, I spent a merry
couple of hours changing the code to use memcpy instead of
strcpy and so on.

Again, I have a program which works fine in Solaris 10, Open
Solaris, and Solaris 11 Express.  It uses a mix of old
functions (hey, if the code still works, why change it, am I
right?) and new functions (if you can call POSIX 2008 "new".)
But OpenIndiana?  I am still baffled as to what combination of
feature test macros I can set to make the program compile, and
am coming to the conclusion that there isn't one.

Did I mention the trouble I've been having with Ubuntu 17.10?
I'll spare you that, but let's just say that putting standard
headers in nonstandard places really really does not help.

I don't really have a solution.  It seems as though the only
thing you can do to ensure that old code continues to work is
to keep a VM imagine with a complete copy of the environment
it used to work in.

Good luck plugging new libraries into that, though.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Jesper Louis Andersen-2
I think the only way to approach a problem like this is by asking:

"How much are you willing to spend on your backwards compatibility?"

Maintaining a long-term-release of a piece of software is no easy feat. It requires effort, and that requires money. If you need stability from an older release and you need control of that release, you have to give the right people some money.

In Solaris, Sun had the advantage that they could use the Zone construction in the OS. You could brand a zone, such that inside the zone, the Solaris (10) system operates as if it were a Solaris 8 or 9 system. This is achieved by manipulating the syscall table of the kernel and handling some syscalls differently. Maintenance of such a compat layer is time-consuming, however. In FreeBSD, you have libcompat for much the same thing: It provides you with a way to run legacy binaries on a new system for a while, so you don't have to upgrade all of your software in one go.

In Android development, the system runs by "API levels" (corresponding somewhat to Erlang/OTP major releases). A given library functionality is *introduced* at some API level, *deprecated* at a higher level and eventually *removed* in an even higher API level. This means that any function is alive over a "window" from introduction to removal.

In practice, one has to cope with changes of a system over time. What is a problem is the rate-of-change, not the change itself. Historically, Erlang is a fairly slow-changing system I think. My older Haskell code rarely compiles, and the recent changes in OCaml also requires far more interaction to make things work again on some code bases.

The changes are likely to require library maintainers to handle several releases and this is where the hard part of the work is. A single project can target a single Erlang release. A library, which may have to span several Erlang releases

* Cannot use a new function when it is introduced. That would break backwards compatibility.
* Cannot use functions which have been removed. That would break forwards compatibility.

How large a deprecation window can be depends largely on factors such as "how common is the function, and how easy is it to change the code?", "Do we have a sponsor who wishes the older versions kept around, paying us to do so?", and so on. You may quickly find it is cheaper for you to upgrade the Erlang/OTP release rather than maintaining and older version of it.



On Sat, Nov 25, 2017 at 2:50 AM <[hidden email]> wrote:
A couple of years ago I was working through a Java book.
Not one of the examples got a clean compile.  Not one.
oddly enough, it was string-handling functions that had
been deprecated, and oddly enough, in my environment the
old functions still did everything I needed.

It's not just Erlang and Java.  I had C code using some of
the classic string functions in ways I had carefully ensured
were correct.  Porting to the next version of the Unix
flavour I was using, the linker screamed at me about unsafe
functions.  Since I wanted other people to use the program
and didn't want them looking down on me, I spent a merry
couple of hours changing the code to use memcpy instead of
strcpy and so on.

Again, I have a program which works fine in Solaris 10, Open
Solaris, and Solaris 11 Express.  It uses a mix of old
functions (hey, if the code still works, why change it, am I
right?) and new functions (if you can call POSIX 2008 "new".)
But OpenIndiana?  I am still baffled as to what combination of
feature test macros I can set to make the program compile, and
am coming to the conclusion that there isn't one.

Did I mention the trouble I've been having with Ubuntu 17.10?
I'll spare you that, but let's just say that putting standard
headers in nonstandard places really really does not help.

I don't really have a solution.  It seems as though the only
thing you can do to ensure that old code continues to work is
to keep a VM imagine with a complete copy of the environment
it used to work in.

Good luck plugging new libraries into that, though.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Lloyd R. Prentice-2
A perhaps all-to-naive suggestion:

1. Suppose we move all new Unicode functions to a new module called ustring, unicode, or some such.

2. Keep the string module as is, but explicitly typespec every function.

 I don't have time to check if Erlang has a cstring type, but if not, create it.

All the best,

Lloyd

Sent from my iPad

On Nov 25, 2017, at 9:10 AM, Jesper Louis Andersen <[hidden email]> wrote:

I think the only way to approach a problem like this is by asking:

"How much are you willing to spend on your backwards compatibility?"

Maintaining a long-term-release of a piece of software is no easy feat. It requires effort, and that requires money. If you need stability from an older release and you need control of that release, you have to give the right people some money.

In Solaris, Sun had the advantage that they could use the Zone construction in the OS. You could brand a zone, such that inside the zone, the Solaris (10) system operates as if it were a Solaris 8 or 9 system. This is achieved by manipulating the syscall table of the kernel and handling some syscalls differently. Maintenance of such a compat layer is time-consuming, however. In FreeBSD, you have libcompat for much the same thing: It provides you with a way to run legacy binaries on a new system for a while, so you don't have to upgrade all of your software in one go.

In Android development, the system runs by "API levels" (corresponding somewhat to Erlang/OTP major releases). A given library functionality is *introduced* at some API level, *deprecated* at a higher level and eventually *removed* in an even higher API level. This means that any function is alive over a "window" from introduction to removal.

In practice, one has to cope with changes of a system over time. What is a problem is the rate-of-change, not the change itself. Historically, Erlang is a fairly slow-changing system I think. My older Haskell code rarely compiles, and the recent changes in OCaml also requires far more interaction to make things work again on some code bases.

The changes are likely to require library maintainers to handle several releases and this is where the hard part of the work is. A single project can target a single Erlang release. A library, which may have to span several Erlang releases

* Cannot use a new function when it is introduced. That would break backwards compatibility.
* Cannot use functions which have been removed. That would break forwards compatibility.

How large a deprecation window can be depends largely on factors such as "how common is the function, and how easy is it to change the code?", "Do we have a sponsor who wishes the older versions kept around, paying us to do so?", and so on. You may quickly find it is cheaper for you to upgrade the Erlang/OTP release rather than maintaining and older version of it.



On Sat, Nov 25, 2017 at 2:50 AM <[hidden email]> wrote:
A couple of years ago I was working through a Java book.
Not one of the examples got a clean compile.  Not one.
oddly enough, it was string-handling functions that had
been deprecated, and oddly enough, in my environment the
old functions still did everything I needed.

It's not just Erlang and Java.  I had C code using some of
the classic string functions in ways I had carefully ensured
were correct.  Porting to the next version of the Unix
flavour I was using, the linker screamed at me about unsafe
functions.  Since I wanted other people to use the program
and didn't want them looking down on me, I spent a merry
couple of hours changing the code to use memcpy instead of
strcpy and so on.

Again, I have a program which works fine in Solaris 10, Open
Solaris, and Solaris 11 Express.  It uses a mix of old
functions (hey, if the code still works, why change it, am I
right?) and new functions (if you can call POSIX 2008 "new".)
But OpenIndiana?  I am still baffled as to what combination of
feature test macros I can set to make the program compile, and
am coming to the conclusion that there isn't one.

Did I mention the trouble I've been having with Ubuntu 17.10?
I'll spare you that, but let's just say that putting standard
headers in nonstandard places really really does not help.

I don't really have a solution.  It seems as though the only
thing you can do to ensure that old code continues to work is
to keep a VM imagine with a complete copy of the environment
it used to work in.

Good luck plugging new libraries into that, though.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Kostis Sagonas-2
On 11/25/2017 04:00 PM, Lloyd R. Prentice wrote:
>
>   I don't have time to check if Erlang has a cstring type, but if not,
> create it.


What _exactly_ is a cstring and what does it have to do with Erlang?

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Lloyd R. Prentice-2

Hi Kostis,

 

This thread has explored the policy of deprecating and dropping functions from the string library. Arguments have been made for and against. The term "cstring" was mentioned in a post long gone by. Perhaps it is not a technical term in any language, and I have inadvertently introduced confusion.  But I take cstring to mean a list of ASCII characters.

 

The suggestion in my previous post was aimed at finding a way to move forward with strong support for Unicode while maintaining a clear distinction between the new Unicode string functions and the currently deprecated string functions.

 

We all agree, I believe, that we'd rather not have a language cluttered up with functions that were once useful but have fallen behind advancing technology.

 

And some posts in this thread contend that the deprecated string functions fall into this category. Thus, they favor a policy that deprecates them and marks them for eventual elimination from the language.

 

The devil in the details here is the word "eventual."

 

But I argue that the currently deprecated functions will be useful as long as the English language is widely used around the world. So why not find a way to clearly distinguish between the deprecated string functions and the Unicode functions without breaking legacy code?

 

Since at this time, I'm guessing, that there is more code in the wild that incorporate the deprecated functions than the Unicode functions, then putting the Unicode functions in a separate module may impose less of a burden on the community.

 

Plus, if and when , if ever, there is strong consensus that the deprecated string functions are of little use to anybody in the Erlang user community, the module as a whole can be dropped from Erlang.

 

Best wishes,

 

Lloyd

 

 

 

 

-----Original Message-----
From: "Kostis Sagonas" <[hidden email]>
Sent: Saturday, November 25, 2017 10:11am
To: [hidden email]
Subject: Re: [erlang-questions] Strings - deprecated functions

On 11/25/2017 04:00 PM, Lloyd R. Prentice wrote:
>
>  I don't have time to check if Erlang has a cstring type, but if not,
> create it.


What _exactly_ is a cstring and what does it have to do with Erlang?

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

scott ribe
On Nov 26, 2017, at 11:33 AM, [hidden email] wrote:
>
> But I argue that the currently deprecated functions will be useful as long as the English language is widely used around the world.

But they are not MORE useful than the new functions for English, since UTF-8 is a strict superset of ASCII.

--
Scott Ribe
https://www.linkedin.com/in/scottribe/
(303) 722-0567

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Strings - deprecated functions

Robert Virding
In reply to this post by Jesper Louis Andersen-2
I think it is perfectly possible to keep the old functions in the same 'string' module in a clean way if you just reorganise the documentation. Now all the functions, both the new and the obsolete, are kept in one alphabetical list which makes it difficult to see which are which and get a clear overview of the functions. Why not just separate the functions into 2 groups, the new and the obsolete, each in its own alphabetical list? This would make it easy to keep the old functions while making it easy for people to choose the newer ones, and migrate code if desired. There would then be no need to get rid of the old functions and break backward compatibility.

Robert


On 25 November 2017 at 15:10, Jesper Louis Andersen <[hidden email]> wrote:
I think the only way to approach a problem like this is by asking:

"How much are you willing to spend on your backwards compatibility?"

Maintaining a long-term-release of a piece of software is no easy feat. It requires effort, and that requires money. If you need stability from an older release and you need control of that release, you have to give the right people some money.

In Solaris, Sun had the advantage that they could use the Zone construction in the OS. You could brand a zone, such that inside the zone, the Solaris (10) system operates as if it were a Solaris 8 or 9 system. This is achieved by manipulating the syscall table of the kernel and handling some syscalls differently. Maintenance of such a compat layer is time-consuming, however. In FreeBSD, you have libcompat for much the same thing: It provides you with a way to run legacy binaries on a new system for a while, so you don't have to upgrade all of your software in one go.

In Android development, the system runs by "API levels" (corresponding somewhat to Erlang/OTP major releases). A given library functionality is *introduced* at some API level, *deprecated* at a higher level and eventually *removed* in an even higher API level. This means that any function is alive over a "window" from introduction to removal.

In practice, one has to cope with changes of a system over time. What is a problem is the rate-of-change, not the change itself. Historically, Erlang is a fairly slow-changing system I think. My older Haskell code rarely compiles, and the recent changes in OCaml also requires far more interaction to make things work again on some code bases.

The changes are likely to require library maintainers to handle several releases and this is where the hard part of the work is. A single project can target a single Erlang release. A library, which may have to span several Erlang releases

* Cannot use a new function when it is introduced. That would break backwards compatibility.
* Cannot use functions which have been removed. That would break forwards compatibility.

How large a deprecation window can be depends largely on factors such as "how common is the function, and how easy is it to change the code?", "Do we have a sponsor who wishes the older versions kept around, paying us to do so?", and so on. You may quickly find it is cheaper for you to upgrade the Erlang/OTP release rather than maintaining and older version of it.



On Sat, Nov 25, 2017 at 2:50 AM <[hidden email]> wrote:
A couple of years ago I was working through a Java book.
Not one of the examples got a clean compile.  Not one.
oddly enough, it was string-handling functions that had
been deprecated, and oddly enough, in my environment the
old functions still did everything I needed.

It's not just Erlang and Java.  I had C code using some of
the classic string functions in ways I had carefully ensured
were correct.  Porting to the next version of the Unix
flavour I was using, the linker screamed at me about unsafe
functions.  Since I wanted other people to use the program
and didn't want them looking down on me, I spent a merry
couple of hours changing the code to use memcpy instead of
strcpy and so on.

Again, I have a program which works fine in Solaris 10, Open
Solaris, and Solaris 11 Express.  It uses a mix of old
functions (hey, if the code still works, why change it, am I
right?) and new functions (if you can call POSIX 2008 "new".)
But OpenIndiana?  I am still baffled as to what combination of
feature test macros I can set to make the program compile, and
am coming to the conclusion that there isn't one.

Did I mention the trouble I've been having with Ubuntu 17.10?
I'll spare you that, but let's just say that putting standard
headers in nonstandard places really really does not help.

I don't really have a solution.  It seems as though the only
thing you can do to ensure that old code continues to work is
to keep a VM imagine with a complete copy of the environment
it used to work in.

Good luck plugging new libraries into that, though.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
123