[erlang-questions] Preloaded modules "lists" dependency

[Björn-Egil Dahlberg]

On 2014-02-17 21:15, Thomas Lindgren wrote:
>
> "The "OTP2" part interests me a lot more. One of my favorite ideas is to
> be able to define the whole supervision tree in a single module, and to
> have it feature more complex components like pools for example. It could
> come with a default pool implementation, with a well defined interface
> (from the point of view of the supervision tree) that allows it to be
> replaced with whichever one you want. So instead of having 10 modules
> describing your application, it could all be in a very visual format ..."

I think these kind of enhancements is the ones that should be researched 
and written about.

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.

// Björn-Egil

>
>
> On Monday, February 17, 2014 3:43 PM, Loïc Hoguin <essen@REDACTED> 
> wrote:
>
>     Thoughts and ideas are not worth a lot until they are tested so I
>     will
>     spare you most details for now. It's still a pretty long read.
>
>     For the "Erlang2" part, there isn't much to say. Erlang is a language
>     that is almost perfect. My conclusions about improving it are that
>     there
>     are very few things that can be improved, and they are mostly edge
>     cases
>     (shadowing would be a big one, and not being able to do (<<
>     B:Len/binary, _/bits >>, Len) in a function clause would be another -
>     but the latter is going to be solved soon as I gather). The rest
>     of it,
>     well, I came pretty much to the same conclusions as Joe, the only
>     thing
>     I would add is a basic form of metaprogramming. Basically you want
>     to be
>     able to do two things: compute some data at compile time, and run
>     tests
>     at compile time (and fail to compile if the tests fail). Optionally
>     would allow you to do some conditional builds to work around
>     issues with
>     a specific version of Erlang. But no macros or other weird stuff that
>     just make the code more complex for no good reasons.
>
>     I'm no language expert and I'm not too interested in this part so
>     don't
>     expect anything from me on that point. If I ever attempt something it
>     would just be a very basic wrapper on top of the current Erlang
>     syntax
>     to allow for compile-time stuff to happen (meaning: outside
>     functions,
>     and perhaps even outside modules entirely).
>
>     The "OTP2" part interests me a lot more. One of my favorite ideas
>     is to
>     be able to define the whole supervision tree in a single module,
>     and to
>     have it feature more complex components like pools for example. It
>     could
>     come with a default pool implementation, with a well defined
>     interface
>     (from the point of view of the supervision tree) that allows it to be
>     replaced with whichever one you want. So instead of having 10 modules
>     describing your application, it could all be in a very visual
>     format in
>     a single module.
>
>     I'm more interested in doing an "OTP2" that targets a different
>     use than
>     long running server applications though. As you might already know, I
>     like video games, and I have tried a few quick prototypes of games
>     with
>     Erlang. I think there is a lot of potential, but the barrier of
>     entry is
>     very high. An "OTP2" geared toward games would help greatly. Games
>     typically have a main loop. There's basically no way around that
>     today
>     because most graphic APIs aren't thread safe. SDL2 was released
>     not too
>     long ago for example, and it still isn't thread safe. But that's
>     not a
>     big problem, Erlang's concurrency can still play a big part. For
>     example, by making the lists module parallelize processing of the
>     list
>     automatically past a certain threshold. Or providing efficient timer
>     capabilities (because the timer module ain't it). And the
>     processes that
>     access the API can always be tied to scheduler 0 to avoid any issues.
>
>     I started playing around making an SDL2 NIF this week-end. The first
>     thing you instantly win is not having to worry about freeing
>     resources
>     (with a few gotchas of course, you can only have so much in
>     memory). The
>     GC does it for you! The second thing you instantly win is Erlang's
>     pattern matching. The article I wrote about matching tic tac toe
>     solutions directly instead of trying to write an algorithm is a good
>     example of that. The code becomes small and clear and you can
>     focus on
>     actually building the game.
>
>     Of course, for anything to come out of these experiments, I have
>     to find
>     a way to not get bored, which may prove difficult. Time will tell.
>
>     On 02/17/2014 01:30 PM, Pierre Fenoll wrote:
>     > Hey Loïc,
>     >
>     > I don't mean to hijack the thread.
>     > Can we have more information on "Erlang2/OTP2"? Your guidelines and
>     > back-of-a-napkin experiments interest me greatly.
>     >
>     >
>     > Cheers,
>     >
>     >
>     >
>     > _______________________________________________
>     > erlang-questions mailing list
>     > erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     > http://erlang.org/mailman/listinfo/erlang-questions
>     >
>
>     -- 
>     Loïc Hoguin
>     http://ninenines.eu <http://ninenines.eu/>
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> Take a look at this: https://github.com/thomasl/gen_app
>
> Here is one application I just started:
>
>   1> gen_app:app_sup(om, [{sup, {sup, om, [om_ets_owner, 
> om_repository_server, om_code_server]}).
>
> Which starts a (dynamic) application 'om' with a supervisor 'om' 
> handling three gen_servers on localhost.
>
> 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.
>
> Best,
> Thomas
>
> 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.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140218/b9e3757a/attachment.htm>