[erlang-questions] Strings - deprecated functions

[Joe Armstrong]

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

please^1000 don't break my old code.

If I'm just reading code and I see strings:somefunc(...) then I'd very
much like to know
that there is only ONE version of the strings module.

If two things have the same name they should be the same.

One of the really really good things about Erlang is that I can take
20 year old code and
recompile it and it just works with a very high probability.

Please don't break my old code by changing the standard libraries.

Just as an aside - in my hobby projects all my library code is in one directory
(not multiple directories - this makes it easy to decide which
directory to put things in)

Libraries have names like  mod.erl thereafter mod_vsn1.erl
mod_vsn2.erl mod_vsn3.erl etc.
and I don't make big changes old module once written.

If by any mechanism whatsoever you can create a situation where two
things with the same
name are significantly different you'll end up with a large number of problems.

Really modules should have no names but be named by (say) the SHA1 of
their content
and that way there would be no naming errors - but we don't really
know how to do this in a convenient
way yet.

Cheers

/Joe








On Wed, Nov 22, 2017 at 8:43 PM,  <lloyd@REDACTED> wrote:
> Dear Gods of Erlang,
>
>
>
> "This module has been reworked in Erlang/OTP 20 to handle unicode:chardata()
> and operate on grapheme clusters. The old functions that only work on
> Latin-1 lists as input are still available but should not be used. They will
> be deprecated in Erlang/OTP 21."
>
>
>
> I'm sorry. I've brought up this issue before and got lots of push back.
>
>
>
> But every time I look up tried and true and long-used string functions to
> find that they are deprecated and will be dropped in future Erlang releases
> my blood pressure soars. Both my wife and my doctor tell me that at my age
> this is a dangerous thing.
>
>
>
> I do understand the importance and necessity of Unicode. And applaud the
> addition of Unicode functions.
>
>
>
> But the deprecated string functions have a long history. The English
> language and Latin-1 characters are widely used around the world.
>
>
>
> Yes, it should be easy for programmers to translate code from one user
> language to another. But I'm not convinced that the Gods of Erlang have
> found the optimal solution by dropping all Latin-1 string functions.
>
>
>
> My particular application is directed toward English speakers. So, until
> further notice, I have no use for Unicode.
>
>
>
> I don't want to sound like nationalist pig, but I think dropping the Latin-1
> string functions from future Erlang releases is a BIG mistake.
>
>
>
> I look up tokens/2, a function that I use fairly frequently, and I see that
> it's deprecated. I look up the suggested replacement and I see lexemes/2.
>
>
>
> So I ask, what the ... is a lexeme? I look it up in Merriam-Webster and I
> see that a lexeme is  "a meaningful linguistic unit."
>
>
>
> Meaning what? I just want to turn "this and that" into "This And That."
>
>
>
> I read further in the Erlang docs and I see "grapheme cluster."  WHAT THE
> ... IS GRAPHEME CLUSTER?
>
>
>
> I look up "grapheme" in Merriam-Webster. Oh it is now all so clear: "a unit
> of a writing system."
>
>
>
> Ah yes, grapheme is defined in the docs. But I have to read and re-read the
> definition to understand what the God's of Erlang mean by a "graphene
> cluster." And I'm still not sure I get it.
>
>
>
> It sounds like someone took a linguistics class and is trying to show off.
>
>
>
> But now I've spent 30 minutes--- time that I don't have to waste trying to
> figure out how do a simple manipulation of "this and that." Recurse the next
> time I want to look up a string function in the Erlang docs.
>
>
>
> SOLUTION
>
>
>
> Keep the Latin-1 string functions. Put them in a separate library if
> necessary. Or put the new Unicode functions in a separate library. But don't
> arbitrarily drop them.
>
>
>
> Some folks have suggested that I maintain my own library of the deprecated
> Latin1 functions. But why should I have to do that? How does that help other
> folks with the same issue?
>
>
>
> Bottom line: please please please do not drop the existing Latin-1 string
> functions.
>
>
>
> Please don't.
>
>
>
> Best wishes,
>
>
>
> LRP
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>