[erlang-questions] Trying to change things

[Michael Turner]

In private e-mail, I wrote, in part:

2010/7/5 Michael Turner <michael.eugene.turner@REDACTED>

> "CHILL is unusual in that it supports two forms of declaration syntax, one
> based on Cobol <http://en.wikipedia.org/wiki/Cobol> and the other on PL/1<http://en.wikipedia.org/wiki/PL/1>."
>  (Wikipedia)
>
> My heart goes out to you. ;-)
>
> You're fighting the inertia of legacy code.  However, the inertia of a
> legacy can cut both ways.  Erlang itself has benefited by the same social
> and institutional inertia you describe.  Erlang survived in part because
> open-sourcing helped circumvent the *formal* objection that -- contrary to a
> recent policy in the late 90s at Ericsson -- it was not independently
> supported.  Realistically, however, Erlang was foundational in a successful
> product.  It takes a long time to get rid of something like that, even if
> you should.  Erlang is an open-sourced legacy, luckily with real legs,
> crossing seas.
>

It occurs to me now that, both in my joke and in the rest of my comments,
there's an underlying message: politically, it seldom hurts to show due
respect for why people have done things a certain way in the past.  If your
company uses CHILL, it probably made sense at one time, and might even make
a lot of sense now.

Take CHILL'S PL/1 and COBOL declaration syntax (please!).  I can see why it
might be important, even now.

Telecom is concurrent-event-intensive, so Erlang is a good match.  However,
with these events, we're not talking about UDP packets, which you can toss
on the floor without much worry.  No, many, if not most, of certain major
classes of events also represent *billing opportunities*, or they at least
relate to billing opportunities in some way that has bottom-line impact for
the telco.

Billing is often done on legacy systems, in COBOL.  Yes, still!  The COBOL
billing code is often hosted on IBM mainframes -- yes, still!  The systems
programming language for those mainframes might still be predominantly PL/1
-- yes, still!  And ultimately, the telecom switches have to be integrated
with the business systems, because nobody's going type all that stuff in
from switch log printouts.  There's not enough paper in the world anyway, to
print it all out.

If CHILL uses PL/1 and COBOL declaration syntax, that might be ugly, but
from a global systems configuration perspective, and from a source code
management perspective, using that syntax might also exceedingly practical.
 It means the CHILL code that runs the switch, the PL/1 code that talks
directly to the switch, and the COBOL code that talks to the PL/1 code, can
*all* share header files.

Now, these facts might actually be irrelevant in your context, in the year
2010.  Maybe your company's business apps are now all written in Java.  But
what if it isn't irrelevant?  What if it's, in fact, mission-critical? Then
writing something in Erlang that can understand PL/1 and COBOL declaration
syntax (don't try Erlang parse transforms at home, at least not at this
stage) would speak very clearly to management, in your favor.  It shows you
can nod toward the necessities of the past while looking toward the future.
 It would be especially cool if you could use Erlang bitstring features to
adhere to any binary (and, where character-oriented, possibly EBCDIC-based)
protocols.


Here's another sales technique that can work.  (If you aren't good at
selling technical ideas to technical people, and then to managers above
them, find somebody in your workplace who is, and convert them to Erlang
ideas the best you can.)

Give a presentation and get the nod of approval for Erlang from the
*smartest* person in your shop, whether they have any real authority or not.

Then teach some Erlang to the person in your shop who is generally regarded
as the slowest.  (Be careful here: the real problem with this person might
be only that they aren't very motivated, because they've gotten bored with
programming.  And if you're lucky, Erlang exposure could change that.)

You now have two very persuasive arguments in your favor:

(1) The endorsement of the brightest.

(2) A defense against the following (very common) management objection to
adopting new technology, "Well, sure, our smartest programmer is probably
right when he agrees with you that [technology X] very powerful and useful.
 For really smart people, maybe [technology X] makes sense.  But we have to
hire -- and make use of -- relatively average programmers as well.
 [Technology X] is probably over their heads."  Running code in Erlang
written by your resident "relatively average" programmer closes the deal.
 Just be careful how you say this.

-michael turner