[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]

[Fred Hebert]

One very important thing that jumped to me while writing LYSE is that it
takes *forever* before getting from "I'm writing stuff in the shell and
a module" to "I have a program I can call from the command-line".

Since the community has apparently settled on, rebar, relx, releases,
etc. There's a crapload of learning to do before tying your hands to
production prototype. See how Go's toolchain works there.

I know this likely gets close to your comments from an earlier e-mail --
we could show OTP sooner to get started faster -- but my objections, I
think, still stand.

It could be interesting to see if a tool-based approach could help.
Rebar templates to set things up, relx to build the release. Bundle-in
tools (eper, recon, eflame, etc?), possibly.

Hell, make a beginner project template that uses raw processes and a
supervisor_bridge above them to get people going *with OTP* without
first needing to understand it all. This later leaves place to replacing
various parts of the project without needing a total rearchitecture of
all connex services running.

Package management and discoverability would likely help there too.

Another one, and I think this is where we lose a lot of people, is
algorithms. Anybody who uses Erlang to shuttle bytes around the place
for the network will tend to have a far better time than someone who
comes around and decides "I'll write a game and rely on math-heavy
stuff".

Or even more generally, "I'll write a thing that requires an algorithm
that uses arrays and assumes O(1) updates". Then, you're directly
screwed. Your A* that uses a loop and a table, your vector
multiplication or whatever, they all go slower than expected.

Maybe maps will help, maybe not. But to me there's no doubt that
functional/immutable algorithms are definitely trickier to write given
the literature. Outside of Okasaki's book (which is for MLs and Haskells
first, so you need to learn them to translate in Erlang!), there is
nearly no source of algorithms that are not in papers. Do we need an
'algorithms in Erlang' tutorial?

Don't get me wrong -- I think once you're set up, the maintainability of
Erlang programs is amazingly good. I've written long blog posts on this.
I also think the structure of programs (like service-oriented, but
within a node) is brilliant. But before you get there, there's a
shitload of hurdles to get through, and few apps or exercises targeted
at beginners to help build their chops or get a good general idea.

More or less, the learning curve of Erlang is Vim-like or Emacs-like.
Sadly, if you want to learn Erlang, you often get told to also learn
Emacs on top of it.

That makes for quite a steep curve, doesn't it?

Regards,
Fred.

On 02/15, Garrett Smith wrote:
> I think this group therapy session is going well. People have
> expressed important feelings and strong emotions. Others have
> practiced good listening and empathy skills.
> 
> So, looking around the circle, I'm now wondering if it makes sense to
> try to summarize the problems we'd like to solve.
> 
> Should we draft a petition to ask Ericsson to change the words behind
> OTP? Some think that's a problem. I'm not here to judge.
> 
> Should we propose to move the distribution protocol of Erlang from to
> something like ZMTP? I don't hear many specific technical objections
> to Erlang distribution protocol(s) but, for the future of the
> language, maybe it's an important problem to look at.
> 
> Should we wrest control of Erlang from Ericsson? For my part, the
> changes over the last few years that Ericsson has driven have been
> very positive for the technology and the community. But is this a case
> where a dictator is only feeding and clothing us, shabbily, to keep us
> from revolt? I don't know. It doesn't *feel* like a problem, or at
> least not a problem that demands a revolution.
> 
> I do have a general angst that other languages could swallow up the
> community of programmers that Erlang is suited for. Go, Clojure,
> Scala, JavaScript/Node, etc. -- looming territorial threats? Drum
> beats through the fog? I don't know - this feels like *personal angst*
> that can be solved through late night sessions of programming with
> Erlang -- solving actual coding problems, putting solutions into
> production, demonstrating 10x productivity over your colleagues, etc.
> 
> For my part, I do have a specific problem, which is that I've found it
> hard to get colleagues to pick up and use this language. And there are
> particular reasons for that. I've observed this process: there's a
> surge of interest, but then a fall off. Then back to their standard
> toolkit, sans Erlang.
> 
> I don't know if this is a problem with Erlang -- it could simply be a
> function of cost/benefit. Erlang costs perhaps 3 - 6 months of
> degraded productivity for a programmer. That's a lot, but I don't
> think it's much different than with other languages. Then it's simply
> a matter of the benefit, or perceived benefit -- does it cover the
> cost?
> 
> Regarding this problem of adoption, I can confidently say that there
> are pointless barriers and friction to adoption in Erlang. The whole
> topic of "how to build an application in Erlang" is *very* hard to
> divine and takes time, trial, and error. That's part of that 3 - 6
> month learning curve, but it goes well beyond it.
> 
> I know, I know. To those of you who think Erlang application
> design/architecture is super straight forward, easy to spot, easy to
> implement correctly -- please bear in mind that you are much smarter
> than a lot of other people. Please consider middle-of-the-curve
> programmers like me.
> 
> If we can simplify and flatten the learning curve to writing canonical
> Erlang applications (and, today, this means OTP compliance), it will
> help adoption and help Erlang track in organizations.
> 
> For me, this is a problem worth investing energy in, big time. That's
> why there's e2. Of course there are lots of angles to invest in:
> books, user groups, conferences, online resources, tools, help on
> mailing lists and IRC and so on.
> 
> Oh yeah, and rebranding OTP *of course* essential to this [1].
> 
> But this is just my personal problem, which I've tried to articulate
> using lots of "I statements" [2]. It doesn't have to be everyone
> else's.
> 
> I would suggest that we wind this group therapy thread down, soon, and
> direct our energies toward identifying specific, important, solvable
> problems that we *genuinely* think are worth solving.
> 
> [1] http://www.youtube.com/watch?v=rRbY3TMUcgQ
> 
> [2] http://en.wikipedia.org/wiki/I-message
> 
> On Sat, Feb 15, 2014 at 9:11 AM, mfidelman <mfidelman@REDACTED> wrote:
> >
> >
> >
> > -------- Original message --------
> > From: John Kemp
> > Date:02/15/2014 9:27 AM (GMT-05:00)
> > To: Steve Vinoski
> > Cc: erlang-questions@REDACTED
> > Subject: Re: [erlang-questions] Erland users group (was re: languages in
> > use? [was: Time for OTP to be Renamed?])
> >
> > On 02/15/2014 09:06 AM, Steve Vinoski wrote:
> >
> > Well, a mechanism for increased interest and adoption is one way. An
> > organization that dispels any myth that Erlang/OTP is "controlled" by
> > Ericsson might be another benefit
> > _______________________________________________
> >
> > Sun/Oracle - Java
> > Microsoft - .NET
> >
> > Doesn't seem to have impeded adoption.
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions