[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?]]]

[J David Eisenberg]

> Message: 6
> Date: Sat, 15 Feb 2014 12:08:45 -0500
> From: Fred Hebert <mononcqc@REDACTED>
> To: Garrett Smith <g@REDACTED>
> Cc: Erlang Questions <erlang-questions@REDACTED>
> Subject: Re: [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?]]]
> Message-ID: <20140215170843.GB589@REDACTED>
> Content-Type: text/plain; charset=us-ascii
>
[snip]
>
> 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?
>

Yes, absolutely. Real-life example while wanting to rewrite a program
in Erlang. I have a text file with 32 names. The last number on the
line tells which position a name should occupy in an array (-1 means
"to be determined by a later part of the algorithm using other data on
the line") For instance:

Nancy,3,2
Henry,4,-1
Marco,1,21
Vinh,1,5

In an imperative language like Java/Perl/etc., no problem -- as I've
been using imperative languages for a decade or two. In Erlang, the
algorithm is not at all obvious. ("When your only tool is recursion,
everything looks like a list.")

> 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.
>

Or, perhaps more to the point, to think functionally from the very
beginning of analyzing a problem. Maybe  a "functional programming
cookbook" would be a good 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?
>
Luckily, I ignored that advice and use vim and/or a GUI text editor,
whichever happens to be more convenient at the time.

> Regards,
> Fred.
>