
Interview with Robert Virding, Creator of Lisp Flavored Erlang - mmastrac
https://medium.com/this-is-not-a-monad-tutorial/interview-with-robert-virding-creator-lisp-flavored-erlang-an-alien-technology-masterpiece-c37003945c#.xpd8tqwpl
======
jhgg
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](https://lfe.gitbooks.io/sicp/content/index.html)

~~~
jperras
> Very exciting and awesome to see Erlang getting love on HN.

 _someone_ is relatively new to HN ;).

[https://news.ycombinator.com/item?id=512145](https://news.ycombinator.com/item?id=512145)

~~~
davidw
Seems more genuine lately though - likely driven by Elixir & Phoenix.

------
im_down_w_otp
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?

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

~~~
im_down_w_otp
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
;-)

------
stingraycharles
In case anyone else is wondering, here is some actual code:

[https://github.com/oubiwann/los/blob/master/examples/no-
macr...](https://github.com/oubiwann/los/blob/master/examples/no-
macros/object-via-closure.lfe)

------
geonnave
Had he named it LIFE, it would feel sooo satisfying :)

------
kruhft
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:

[http://busfactor1.ca/bin/eturia/lib/sigil/the-order-of-
symbo...](http://busfactor1.ca/bin/eturia/lib/sigil/the-order-of-
symbols.txt.html)

Feedback appreciated.

