Regarding standard library inconsistencies...
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?
Posted by im_down_w_otp on Feb 29, 2016, 11:05 PM
Tags
Related issues
- GLES isn't a bad way to teach graphics but I wish there was a middle ground between it and VK.
- > [Edit: note that the above video is "content" so if you're not used to the style it might be offputting but I'm into it] I hate that i...
- And thats why its a large language model not a large skin cancer recognition model or large creative thinking model I hate that people th...
- I hate that this article is talking about Photocraft killing Photoshop because of AI as though Ivan Kutskir didn't build Photopea years a...
- That's a fair complaint, but for the most part that only applies to the faces (which would be an absolute nightmare to hand animate in sy...
- I wish there was something that could be done beyond feeling powerless.
Raise real-world problems, find people facing the same issue, and discuss solutions.5,000 issues0 comments
complaint (Other)
GLES isn't a bad way to teach graphics but I wish there was a middle ground between it and VK.
New> [Edit: note that the above video is "content" so if you're not used to the style it might be offputting but I'm into it] I hate that i...
NewAnd thats why its a large language model not a large skin cancer recognition model or large creative thinking model I hate that people th...
NewI hate that this article is talking about Photocraft killing Photoshop because of AI as though Ivan Kutskir didn't build Photopea years a...
That's a fair complaint, but for the most part that only applies to the faces (which would be an absolute nightmare to hand animate in sy...
I wish there was something that could be done beyond feeling powerless.
I don’t hate taxes per se but I hate that the government will take tax dollars earmarked for one purpose, which is how they got the tax a...
I've never thought SF Symbols were beautiful.
Regarding standard library inconsistencies...
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?
Comments (0)
No comments yet. Start the discussion.