Very exciting and awesome to see Erlang getting love on HN.
For those who might have missed it, there is also an accompanying book that is a work in progress of converting the MIT classic "Structure and Interpretation of Computer Programs" to Lisp Flavored Erlang here: https://lfe.gitbooks.io/sicp/content/index.html
Regarding standard library inconsistencies... can consistency be brought to some nearish-term future release, like R20 or something, which brings much needed consistency to OTP while providing temporary backward compatibility through reordering shim functions + guard clauses?
split(List, N) when is_integer(N), N >= 0, is_list(List) ->
split(N, List);
split(N, List) when is_integer(N), N >= 0, is_list(List) ->
case split(N, List, []) of
{_, _} = Result -> Result;
Fault when is_atom(Fault) ->
erlang:error(Fault, [N,List])
end;
split(N, List) ->
erlang:error(badarg, [N,List]).
It makes the ordering inconsequential in this case... which I can see as a sort of transient bad thing.
You could also straight up migrate the API and provide a set of compatibility_mode parse transformations to be included which would take old-signature invocations and replace them at compile-time with the new ones, forcing really only a build-phase change to existing code bases until they make the change on their own.
I dunno. It's been an annoying problem for a long time and a common complaint amongst newbie Erlang developers, but I guess at the end of the day you just get used to it, so as you get more experienced you probably just care less about it. That said I'd love to see better adoption of Erlang, and "simple" things like this might assist with that.
Lower barrier of entry to the stages of scaffold-project -> write -> build -> test cycles is one of the things that's really appealing about Elixir by comparison.
Is this kind of thing of any interest at all to Ericsson to accept upstream if the community were to go through the drudgery of combing the stdlib for the places these changes should be made and providing options for transition/deprecation paths?
Erlang tends to be pretty conservative. Its evolution is a bit different from many open source languages: before it got very popular at all, it got used in some very critical places.
Yes. I know. However those places also aren't aggressive about upgrading their Erlang versions unless there's a critical patch, and even then sometimes those are back-ported by the places creating, maintaining, and deploying their Erlang systems/software (such as one of my previous employers).
Additionally, these changes are largely superficial, not functional. They're in the "make it pretty" part of the "first make it work, then make it pretty, then make it fast" ethos.
It's purely developer experience focused of course. The machine doesn't care what order the arguments are in. Well that may not be entirely true. I'd have to look more closely at the function-head matching implementation to see if there's some benefit or hinderance in putting non-scalar types first in the argument list... but that would be in the "make it fast" part that comes later ;-)
For those looking to learn the basics of Lisp and macro programming from the 'bare essentials', you might be interested in my "The Order of Symbols", a WIP course I'm developing:
For those who might have missed it, there is also an accompanying book that is a work in progress of converting the MIT classic "Structure and Interpretation of Computer Programs" to Lisp Flavored Erlang here: https://lfe.gitbooks.io/sicp/content/index.html