[erlang-questions] If you are homesick for object.selector
Sat Jan 26 03:26:01 CET 2013
>> Loïc Hoguin wrote:
>> (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.
The one and only example I have seen so far
was a one-liner involving an imaginary game.
If it isn't an imaginary game, my apologies.
But it was still a one liner, and without any
context to make it interpretable.
> I'm sure you can imagine other examples.
I don't want imaginary examples. Like I said,
please let's have about a page of code, with enough
context to make it intelligible.
> Or perhaps you are going to tell me you never had to manage big amounts
> of related data in Erlang? (Wouldn't surprise me.)
I've had to manage sufficient data for a single run
to take days.
>> 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.
Sigh. But does *CARRYING OUT* that access or update involve
running complex code? I mean, fetching a field from a *record*
doesn't count as complex code, but fetching an entry from a
'dict' does count as running complex code, way beyond what
Person#person.name could do.
> 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.
If confronted with that task, I will refuse to do it.
I will _definitely_ do something to generate that code
automatically, just as we have leex and yecc and other
tools for generating code.
> DSL still maps to functions which needs to access and update these
> values, and that code is still painful to write.
Yes, but using a DSL ***means*** that you do not write that code
more than once.
> 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.
I write small-scale task-specific code generators a LOT.
It's not quite as easy as falling off a log, but it's
easier than, say, getting a complex regular expression right.
Yes, I make mistakes when I do this, and yes, I have to test
a fair bit. But most of this is testing I would have had to
do *anyway* and mistakes I would have made *anyway* except
that instead of a mistake being made once, found by one test,
and fixed with a single fix, there would have been dozens of
> 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.
Does there exist such a thing as a bug-free implementation of
anything in PHP?
In all seriousness, I use small-scale code generation BECAUSE
IT SAVES ME TIME. Coding time, testing time, debugging time.
> 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.
Again, I think we have strayed from the original path,
which had nothing to do with updating and everything to
do with the perceived verbosity of Person#person.name.
If you want ease of updating, there's no shame in using F#.
More information about the erlang-questions