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

[Garrett Smith]

On Fri, Jan 25, 2013 at 10:51 AM, Fred Hebert <mononcqc@REDACTED> wrote:
>
> On 01/25, Lo�c Hoguin wrote:
>> *Data*. Not code. Access. Update. That's all that's needed.
>
> Alright, here's a 15 minutes attempt at getting some monster design
> working based on tuple lists, but any data structure that's dynamic
> enough (not records) would probably do. No benchmarking, no testing,
> but you can pretty much use lists of accessors in verbose manner, but
> less verbose than your usual dictionary or k/v use.

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]

Imagine the boundless creativity Erlang will never harness because
it's so hard to navigate deeply nested data structures using dots!

Or course this is absurd. But it's the basis of this thread.

The debate has become how we should represent a particular operation,
when in Erlang, it should be clear -- you use a function:

  get_strength(Char)

and if that contract is overly specific:

  get_attr(strength, Char)

Inside that function you can do whatever want. The function is a
contract. It's easy to type, easy to read, easy to use.

You want to update?

  set_attr(strength, "muscley", Char)

So, a game developer has a requirement to easily and efficiently
navigate a deeply nested data structure, and optionally apply
transformations along the way. [2] Okay, that's the requirement.
Erlang term manipulation can *conceivably* be used for that, but upon
casual inspection, it's *obviously* not well suited.

I offhand don't know what is best suited as an implementation. It's an
engineering problem.

But I do know that however it's implemented, gaming programmers should
not be exposed to those details. They should get a simple, easy to use
interface. If Erlang functions are too painful or otherwise unnatural
to use, create a DSL.

With a DSL, game programmers can use whatever syntax they care to
invent. And you can plug in engines behind that interface as you see
fit.

Depending on the performance, scalability, and reliability
requirements, the implementation of this gaming infrastructure could
be wildly different, of course.

Here are some other ways you *could* implement the
game-engine-state-problem described:

- ets/dets

- Relational database (SQLite, MySQL, PostreSQL)

- Graph database (I only know of Neo4J, but Erlang talks to Java)

- Redis

- Riak

- Some crazy heap navigator in C over a port -- or a NIF!

- Python + ErlPort

- Embedded Lua with an R backend -- go crazy!!

Whatever. It all sits behind an interface that is clear, simple, even fun!

Now, as far as using Erlang to create DSLs, I think you have an
interesting topic. [3]

Garrett

[1] https://github.com/languages

[2] I'm reminded of the coding horror that is jQuery

[3] I'd point to Eric Merrit's outstanding with with Joxa
(http://joxa.org) as an example of what can be done with core Erlang
and the Erlang tool chain