[erlang-questions] If you are homesick for object.selector

Jeremy Ong jeremy@REDACTED
Fri Jan 25 21:08:28 CET 2013


I work at a game-development studio so I can chime in on some of this.

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.

Incidentally, I can understand why bringing up OO ruffles feathers, but
what is wrong about discussing how to represent objects themselves?

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


On Fri, Jan 25, 2013 at 10:34 AM, Garrett Smith <g@REDACTED> wrote:

> On Fri, Jan 25, 2013 at 12:26 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> > On 01/25, Garrett Smith wrote:
> >> Let's compare this:
> >>
> >>   Strength = '?'(Char, [stats,skills,strength])}
> >>
> >> to this:
> >>
> >>   Strength = Char.stats.skills.strength
> >>
> >> Now, which would a beginner prefer? The first version is *terrifying*.
> >> And if the programmer *could* brave the syntax, what about all that
> >> extra typing?? Just looking at that code makes my fingers tired :(
> >>
> >> That's why Ruby is #2 on github language ranks and Erlang isn't even
> >> in the top 10! [1]
> >
> > Of course it's terrible. It's a 15 minutes attempt to show it's doable
> > to navigate deeply nested data structures. I might as realistically make
> > a function that accepts:
> >
> > Char = set(new, stats,skills,strength, 50)
> > Strength = get(Char, stats,skills,strength)
>
> Indeed, I was just using your code as a straw man :)
>
> When chaining operations like that, I too use lists. It's the natural
> thing to do in Erlang for that case I think.
>
> -snip-
>
> > There are reasons for Erlang to not be that used, but accessors for deep
> > data structures are likely not the most important part of it. I'd
> > probably bet on the difficulty to translate algorithms that assume O(1)
> > access to hashes or arrays, with destructive updates, as a significant
> > barrier of entries with far fewer easy workarounds.
> >
> > That's all speculation anyway.
>
> Precisely!
>
> Garrett
> _______________________________________________
> 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/20130125/38082481/attachment.htm>


More information about the erlang-questions mailing list