<div dir="ltr"><div style>I work at a game-development studio so I can chime in on some of this.</div><div style><br></div><div style>First, real world data =/= designed data. What I mean by this is that real world data (mined from measurements or analytics or something) tends to fit certain patterns and have even levels of nesting, so that something like nested proplists or dicts can be easy to reason about. Once we are referring to data that pertains to game data, the data isn't "nice" anymore. To take Loic's example: suppose I design a character to have an arsenal of weapons. When I initially implement this, a flat data structure is fine. Later however, design changes, and now some weapons (not all) can be outfitted with a weapon add-on, like a scope or laser sight. Other weapons can be upgraded. A future design might even allow for the scope itself to be upgraded. Coming up with a way to represent this in Erlang such that it can be *flexibly* expanded on without changing api and implementation everywhere is very difficult. I can say that nested proplists and dicts and lists are very cumbersome to work with because there are no enforced contracts with the developer.</div>
<div><br></div>Incidentally, I can understand why bringing up OO ruffles feathers, but what is wrong about discussing how to represent objects themselves?<div><br></div><div style>Personally, I wish something like C-structs were available I suppose. The fact is, sometimes, data is deeply nested, and we should be able to talk about nested representations for them (with convenient accessors).</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 25, 2013 at 10:34 AM, Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Jan 25, 2013 at 12:26 PM, Fred Hebert <<a href="mailto:mononcqc@ferd.ca">mononcqc@ferd.ca</a>> wrote:<br>
> On 01/25, Garrett Smith wrote:<br>
>> Let's compare this:<br>
>><br>
>>   Strength = '?'(Char, [stats,skills,strength])}<br>
>><br>
>> to this:<br>
>><br>
>>   Strength = Char.stats.skills.strength<br>
>><br>
>> Now, which would a beginner prefer? The first version is *terrifying*.<br>
>> And if the programmer *could* brave the syntax, what about all that<br>
>> extra typing?? Just looking at that code makes my fingers tired :(<br>
>><br>
>> That's why Ruby is #2 on github language ranks and Erlang isn't even<br>
>> in the top 10! [1]<br>
><br>
> Of course it's terrible. It's a 15 minutes attempt to show it's doable<br>
> to navigate deeply nested data structures. I might as realistically make<br>
> a function that accepts:<br>
><br>
> Char = set(new, stats,skills,strength, 50)<br>
> Strength = get(Char, stats,skills,strength)<br>
<br>
</div>Indeed, I was just using your code as a straw man :)<br>
<br>
When chaining operations like that, I too use lists. It's the natural<br>
thing to do in Erlang for that case I think.<br>
<br>
-snip-<br>
<div class="im"><br>
> There are reasons for Erlang to not be that used, but accessors for deep<br>
> data structures are likely not the most important part of it. I'd<br>
> probably bet on the difficulty to translate algorithms that assume O(1)<br>
> access to hashes or arrays, with destructive updates, as a significant<br>
> barrier of entries with far fewer easy workarounds.<br>
><br>
> That's all speculation anyway.<br>
<br>
</div>Precisely!<br>
<span class="HOEnZb"><font color="#888888"><br>
Garrett<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>