[erlang-questions] Preloaded modules "lists" dependency
Mon Feb 17 15:14:31 CET 2014
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.
> erlang-questions mailing list
More information about the erlang-questions