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

[Loïc Hoguin]

On 01/25/2013 04:09 AM, Richard O'Keefe wrote:
>
> On 25/01/2013, at 3:08 PM, Loïc Hoguin wrote:
>
>> On 01/25/2013 01:31 AM, Richard O'Keefe wrote:
>>>
>>> On 24/01/2013, at 3:37 PM, Loïc Hoguin wrote:
>>>> But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person).
>>>
>>> I thought the complaint was that Person#person.name is not polymorphic;
>>> my point was that name(Person) _can_ be polymorphic, if you seriously
>>> want it to be.
>>
>> It's about ease of use, reducing the extra steps (or plane flight in the case of Erlang) to get the work done.
>
>
> (1) Please let's have a real concrete example of about 1 page,
>      not imaginary one-liners, with names that turn out to be
>      not as intention-revealing as they look.

It's a real concrete example. I'm sure you can imagine other examples. 
Or perhaps you are going to tell me you never had to manage big amounts 
of related data in Erlang? (Wouldn't surprise me.)

> (2) Person#person.name is just a field selector; it can only fetch
>      a stored data.  The "frames" analogue, Person~name, has the
>      same basic property.  The Smalltalk analogue, person name,
>      or the C# analogue, person.name, can run arbitrary code, which
>      is much more powerful.
>
>      Are we debating whether Person~name, with the same fundamental
>      limitation as field access in C or Java or ML, is a really big
>      improvement over Person#person_name?
>
>      Or has the idea crept in that Person.name might run complex code?

*Data*. Not code. Access. Update. That's all that's needed.

> I note that www.missioncriticalit.com claim to be able to generate
> about 90% of the code in a business system (in Java, C#, or Mercury)
> from semantic models.
>
> That's _really_ where I think the big gains are going to come from.
> And I expect the core Erlang ideas to be good for such systems even
> if the Erlang language is replaced by a different embodiment of them.
>
> (It should be clear, but if not:  each Domain needs its own Domain
> Specific Language.  "Then Erlang needs that DSL." doesn't really
> make sense.  'Then Erlang needs its own toolkit to make building
> good DSLs easy' does make sense and I think it's true.

Let me tell you something about yourself.

You are confronted with the problem of wasting a lot of time writing 
basement level code to access and update deep values. You think "Great! 
I can write DSL or combinators to solve this!". Now you got two 
problems, and you haven't come any closer to solving the first one. The 
DSL still maps to functions which needs to access and update these 
values, and that code is still painful to write. Your next step is to 
think "Great! Let's generate all that code then!". Now you got three 
problems, and you better hope to have not made any error when writing 
that code generator or you'll waste a lot more time. Speaking of time, 
by the time you get to that point the PHP developer has already long 
finished his bug-free implementation of the same code and is moving on 
to other tasks.

There's absolutely no need for a DSL. All you have to do is have the 
correct interface, like character:add_to_inventory(Item, Character) and 
your game logic is clear. The problem is that the code on the other side 
of this interface is messy, prone to errors and takes too damn long to 
write with current Erlang, because Erlang focuses so much on functions 
that it totally forgot that in the end it's all about data and it'd be 
nice to actually do something meaningful with it.

>>> 	character addToInventory: item
>>
>> Let me stop you right there. Nobody said anything could change Character.
>
> And where does that line of code say anything _does_ change Character?
> The _association_ between 'character' and 'item' changes, somehow.
> That doesn't mean 'character' has to change.
>
> That's the point, really.

That's still besides the point. If it's not Character.inventory it's 
State.character and State.inventory. Doesn't make updating any easier.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu