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