[erlang-questions] Strings - deprecated functions

[Lloyd R. Prentice]

Hello,

+1 re: the ordering of modules and functions in stdlib.

I'm fine with alphabetical ordering. But I do feel that complementary schemes are worth consideration.

 So here's a challenge:

Suppose we have a parallel ordering of modules and functions within modules by frequency of use in the wild.

Shouldn't be too hard to generate with a few well-chosen NLP tools.

I'd do it myself if I could spare a Saturday morning. But I can't. 

So I'll offer a bounty--- a $100.00 USD Amazon gift card to first person who generates such a list based on a statistical representative sample of all Erlang source code posted on GitHub within the next month.

All the best,

LRP


> On Nov 27, 2017, at 4:22 PM, Loïc Hoguin <essen@REDACTED> wrote:
> 
> The reason this PR was closed is a little ridiculous.
> 
> stdlib has erl_internal and other modules before most modules that are useful to most people and the important modules are effectively hidden in this confusing mess of useful and not-so-useful-at-all modules.
> 
> Meanwhile the compiler application has exactly one module right now; you're not going to confuse anyone by adding a couple more modules.
> 
> Ridiculous.
> 
>> On 11/27/2017 06:01 PM, Anthony Ramine wrote:
>> I don't particularly care about the old functions myself (if you want to run old code, just run a damn old VM, problem solved), but a way to reorganise the documentation to accommodate for that would also bring closure to  https://github.com/erlang/otp/pull/363, which would be nice.
>>> Le 27 nov. 2017 à 03:03, Robert Virding <rvirding@REDACTED> a écrit :
>>> 
>>> 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.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 
> -- 
> Loïc Hoguin
> https://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions