<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2014-02-17 21:15, Thomas Lindgren
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1392668140.48109.YahooMailNeo@web140102.mail.bf1.yahoo.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=iso-8859-1">
      <div>
        <div><span><br>
          </span></div>
        <div><span>"</span><span>The "OTP2" part interests me a lot
            more. One of my favorite ideas is to</span><span> </span></div>
        <span>be able to define the whole supervision tree in a single
          module, and to </span><br>
        <span>have it feature more complex components like pools for
          example. It could </span><br>
        <span>come with a default pool implementation, with a well
          defined interface </span><br>
        <span>(from the point of view of the supervision tree) that
          allows it to be </span><br>
        <span>replaced with whichever one you want. So instead of having
          10 modules </span><br>
        <span>describing your application, it could all be in a very
          visual format ..."</span><br>
      </div>
    </blockquote>
    <br>
    I think these kind of enhancements is the ones that should be
    researched and written about.<br>
    <br>
    I would like to see either an extensive blog article, a white paper
    or an EUC / Factory presentation on different approaches or
    extensions to the existing OTP principals. I don't want to see code.
    I want to see how it would fit together, described using small words
    and visual aids.<br>
    <br>
    // Björn-Egil<br>
    <br>
    <blockquote
      cite="mid:1392668140.48109.YahooMailNeo@web140102.mail.bf1.yahoo.com"
      type="cite">
      <div>
        <div class="yahoo_quoted"> <br>
          <br>
          <div>
            <div>
              <div dir="ltr"> On Monday, February 17, 2014 3:43 PM, Loïc
                Hoguin <a class="moz-txt-link-rfc2396E" href="mailto:essen@ninenines.eu"><essen@ninenines.eu></a> wrote:<br>
              </div>
              <blockquote>
                <div class="y_msg_container">Thoughts and ideas are not
                  worth a lot until they are tested so I will <br>
                  spare you most details for now. It's still a pretty
                  long read.<br>
                  <br>
                  For the "Erlang2" part, there isn't much to say.
                  Erlang is a language <br>
                  that is almost perfect. My conclusions about improving
                  it are that there <br>
                  are very few things that can be improved, and they are
                  mostly edge cases <br>
                  (shadowing would be a big one, and not being able to
                  do (<< <br>
                  B:Len/binary, _/bits >>, Len) in a function
                  clause would be another - <br>
                  but the latter is going to be solved soon as I
                  gather). The rest of it, <br>
                  well, I came pretty much to the same conclusions as
                  Joe, the only thing <br>
                  I would add is a basic form of metaprogramming.
                  Basically you want to be <br>
                  able to do two things: compute some data at compile
                  time, and run tests <br>
                  at compile time (and fail to compile if the tests
                  fail). Optionally <br>
                  would allow you to do some conditional builds to work
                  around issues with <br>
                  a specific version of Erlang. But no macros or other
                  weird stuff that <br>
                  just make the code more complex for no good reasons.<br>
                  <br>
                  I'm no language expert and I'm not too interested in
                  this part so don't <br>
                  expect anything from me on that point. If I ever
                  attempt something it <br>
                  would just be a very basic wrapper on top of the
                  current Erlang syntax <br>
                  to allow for compile-time stuff to happen (meaning:
                  outside functions, <br>
                  and perhaps even outside modules entirely).<br>
                  <br>
                  The "OTP2" part interests me a lot more. One of my
                  favorite ideas is to <br>
                  be able to define the whole supervision tree in a
                  single module, and to <br>
                  have it feature more complex components like pools for
                  example. It could <br>
                  come with a default pool implementation, with a well
                  defined interface <br>
                  (from the point of view of the supervision tree) that
                  allows it to be <br>
                  replaced with whichever one you want. So instead of
                  having 10 modules <br>
                  describing your application, it could all be in a very
                  visual format in <br>
                  a single module.<br>
                  <br>
                  I'm more interested in doing an "OTP2" that targets a
                  different use than <br>
                  long running server applications though. As you might
                  already know, I <br>
                  like video games, and I have tried a few quick
                  prototypes of games with <br>
                  Erlang. I think there is a lot of potential, but the
                  barrier of entry is <br>
                  very high. An "OTP2" geared toward games would help
                  greatly. Games <br>
                  typically have a main loop. There's basically no way
                  around that today <br>
                  because most graphic APIs aren't thread safe. SDL2 was
                  released not too <br>
                  long ago for example, and it still isn't thread safe.
                  But that's not a <br>
                  big problem, Erlang's concurrency can still play a big
                  part. For <br>
                  example, by making the lists module parallelize
                  processing of the list <br>
                  automatically past a certain threshold. Or providing
                  efficient timer <br>
                  capabilities (because the timer module ain't it). And
                  the processes that <br>
                  access the API can always be tied to scheduler 0 to
                  avoid any issues.<br>
                  <br>
                  I started playing around making an SDL2 NIF this
                  week-end. The first <br>
                  thing you instantly win is not having to worry about
                  freeing resources <br>
                  (with a few gotchas of course, you can only have so
                  much in memory). The <br>
                  GC does it for you! The second thing you instantly win
                  is Erlang's <br>
                  pattern matching. The article I wrote about matching
                  tic tac toe <br>
                  solutions directly instead of trying to write an
                  algorithm is a good <br>
                  example of that. The code becomes small and clear and
                  you can focus on <br>
                  actually building the game.<br>
                  <br>
                  Of course, for anything to come out of these
                  experiments, I have to find <br>
                  a way to not get bored, which may prove difficult.
                  Time will tell.<br>
                  <br>
                  On 02/17/2014 01:30 PM, Pierre Fenoll wrote:<br>
                  > Hey Loïc,<br>
                  ><br>
                  > I don't mean to hijack the thread.<br>
                  > Can we have more information on "Erlang2/OTP2"?
                  Your guidelines and<br>
                  > back-of-a-napkin experiments interest me greatly.<br>
                  ><br>
                  ><br>
                  > Cheers,<br>
                  ><br>
                  ><br>
                  ><br>
                  > _______________________________________________<br>
                  > erlang-questions mailing list<br>
                  > <a moz-do-not-send="true" shape="rect"
                    href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
                  > <a moz-do-not-send="true" shape="rect"
                    href="http://erlang.org/mailman/listinfo/erlang-questions"
                    target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
                  ><br>
                  <br>
                  -- <br>
                  Loïc Hoguin<br>
                  <a moz-do-not-send="true" shape="rect"
                    href="http://ninenines.eu/" target="_blank">http://ninenines.eu</a>
                  <div class="yqt5349722011" id="yqtfd18177"><br>
                    _______________________________________________<br>
                    erlang-questions mailing list<br>
                    <a moz-do-not-send="true" shape="rect"
                      href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
                    <a moz-do-not-send="true" shape="rect"
                      href="http://erlang.org/mailman/listinfo/erlang-questions"
                      target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
                  </div>
                  <br>
                  <br>
                </div>
              </blockquote>
            </div>
          </div>
        </div>
        <div><span><br>
          </span></div>
        <div><span>Take a look at
            this: <a class="moz-txt-link-freetext" href="https://github.com/thomasl/gen_app">https://github.com/thomasl/gen_app</a></span></div>
        <div><span><br>
          </span></div>
        <div><span>Here is one application I just started:</span></div>
        <div><span><br>
          </span></div>
        <div><span>  1> gen_<a class="moz-txt-link-freetext" href="app:app_sup(om">app:app_sup(om</a>, [{sup, {sup, om,
            [om_ets_owner, om_repository_server, om_code_server]}).</span></div>
        <div><span><br>
          </span></div>
        <div><span>Which starts a (dynamic) application 'om' with a
            supervisor 'om' handling three gen_servers on localhost.</span></div>
        <div><span><br>
          </span></div>
        <div><span>Caveats: Somewhat inelegant notation so far, and you
            still need 'application' for the more complex cases. No pool
            handling at the moment either. But it's pretty compact.</span></div>
        <div><span><br>
          </span></div>
        <div><span>Best,</span><br>
        </div>
        <div>Thomas</div>
        <div><br>
        </div>
        <div>PS. Apologies to those I've written to recently -- Yahoo is
          acting up, perhaps due to THE HUGE THREADS we're having, so
          I'm having some trouble reading my mail at the moment.
          Sporadically hanging client, etc.</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>