[erlang-questions] Preloaded modules "lists" dependency

[Loïc Hoguin]

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
> http://erlang.org/mailman/listinfo/erlang-questions
>

-- 
Loïc Hoguin
http://ninenines.eu