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

[Fred Hebert]

It's a definite possibility. I still work in Erlang with no tools at
all past vim and tmux to get a shell right next to it, and tend not to
mind verbosity *if* it makes maintenance and readability simpler, less
ambiguous.

I've always considered myself to be a rather slow programmer, and I
don't especially care about how fast I am at writing code nearly as much
as how fast code can be written so I understand it *correctly* in as
short a time as possible.

That's why I can be in favour of trying to get terse code or compact
representations (pattern matching is the best thing for this), but I
tend to dislike things like overloading existing constructs, which then
force me to understand more and more of the context that surrounds a bit
of code to know what it does. Sometimes the terseness of code ends up
being a pure trade off between speed of writing and speed of
understanding (complex regular expressions compared to writing a little
one-off parser can be a good example of this debate).

Given I'm not having a personal problem understanding most Erlang code
that respects OTP principles, and that understandability comes before
most other factors to me (and I care about my own opinion very much!),
I tend to take ideas such as overloading well-defined semantics for the
sake of terseness as a long term threat to a lot of the things that
make Erlang great to me right now.

I think a lot of people make the implicit choice of pushing more code
faster, thinking "oh it's not gonna be around in 15 years". I think this
gives an unfair advantage to features that improve productivity before
maintainability (when the objectives clash). It's a decision I
frequently make. I sometimes think I should force myself to
take the egotistical position that I know better and don't
want to deal with all the experimental one-off prototypes that ended up
being pushed in production by eager middle-managers as what I want to
end up maintaining in the future.

It's a very hand-wavy position, and I realize there's no moral high
ground, that projects are different and that various developers have
different priorities, capacities to understand an memorize.

I just feel maintainability should be seen as more important than it
is seen in general -- after all, roughly 30% of the programmer time spent
in a project is for development, 70% of the time spent is in maintenance.
Of that 70%, between 50% to 90% of it is spent trying to figure out what
the hell the code is doing (that's 20% to 60% of the whole project's
life!)

With these numbers, it seems insane to optimize for fast writing instead
of fast understanding.

Regards,
Fred.

P.S. That got long and rant-y way faster than I expected! Sorry!

On 01/24, Henning Diedrich wrote:
> It wasn't originally about chainability, was it.
> 
> I'd support that one won't usually have deep chains, except when trying things, scripting, also in games. It would indicate something is off.
> 
> So the chaining is one thing, but that verbosity, I think it is played down too nonchalantly. It does make programming harder. It would be a serious win to overcome that. I can only suspect that one doesn't see it that much anymore once you are fully used to it but I am positive it would benefit everybody.
> 
> Best, 
> Henning 
> 
> 
> On Jan 24, 2013, at 6:41 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> 
> > I'm not making a judgement call on any of it, whether it's worth it or
> > not or something to aim for, at least not in that post.
> > 
> > It just striked me as somewhat peculiar to ask to change the
> > associativity of one of the most basic operators of a language to be
> > able to get something that looks different/shorter to call functions
> > around following countless arguments on the same topic in the last few
> > days.
> > 
> > I don't know why making calls chainable that way is *that* desirable, as
> > I tend to prefer unambiguous (even if verbose) code to optimized code
> > throughput on a per-character basis,  but Evan Miller certainly desires
> > it a whole damn lot. He's got to make that square peg fit real hard :)
> > 
> > Regards,
> > Fred
> > 
> > On 01/24, Max Lapshin wrote:
> >> On Thu, Jan 24, 2013 at 8:36 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> >> 
> >>> On 01/24, Evan Miller wrote:
> >>>> Cost = Character:weapon():ability():cost()
> >>>> 
> >>>> While laughing maniacally and dancing around a burning pyre of Prolog
> >>> books
> >>> 
> >>> I can't help myself thinking you're one of the most dedicated people
> >>> working on making the square peg fit the seemingly round hole on this
> >>> mailing list :)
> >>> 
> >> 
> >> 
> >> Evan develops one of the most developed and most widely used ORM on Erlang,
> >> so you have to admit that he definitely has success in this complicated
> >> task.
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>