[erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function)

Garrett Smith g@REDACTED
Wed Jan 23 02:56:26 CET 2013


On Tue, Jan 22, 2013 at 5:41 PM, Simon St.Laurent <simonstl@REDACTED> wrote:
> Evan Miller wrote:
>>
>> I worry that Erlang is missing out on a lot of potential developer
>> talent because the platform's benefits tend to be back-loaded: it's
>> great for the big-scale stuff, but it can be painful for a newcomer
>> just tinkering around and seeing if stuff works. A hobbyist has to be
>> both extremely tenacious and perhaps delusional to stick with Erlang
>> long enough to realize the platform's benefits.
>
> I agree that there are a lot of people who could benefit from Erlang, and
> who don't participate because they think it's only for huge systems.  I'm
> having fun, but will admit that I could get a lot of things done faster in
> other languages.

"Huge system" feels abstract to me. In my experience, "systems" tend
to extend beyond a single language, VM, OS process, server -- maybe
data center.

I think Erlang is great for programming in general. It helps to
enforce -- or at least encourage adherence to -- certain principles
that are applicable anywhere:

- Side effects are the source of myriad problems and should be avoided
when possible

- Isolation (a bulwark) is the first requirement of reliability

- Fault detection and recovery (restoring to a known state) is the
second requirement of reliability

- Less code is easier to understand and maintain than more code

- State has costs that are easy to underestimate (and hiding these
costs through language features is a disservice)

These principles will help a programmer build bigger, more complex
systems -- but they apply equally well to to small, simple programs.

I've been back in "C" world lately and it looks completely different
to me after having spent a few years with Erlang (I think any
functional language would apply though):

- Throw a dart a wall of C code and chances are you'll hit something
that's *terrifyingly* bad -- the fact that some code works at all is a
result of brute force trial and error (testing?) and hacking (bug
fixing?) [1]

- Function scope seems arbitrary -- it's sometimes hard to understand
why the C programmer uses functions at all -- e.g. a single function
containing 1000 lines of code with interspersed comments would be just
as readable and maintainable

- The world of side effects in C is sobering -- between global
variables and unconstrained pointer operations (missing const, casts,
etc.) the "obviously correct" snippet of code is unicorn rare

True, that's your average C program, but my rant extends to other
languages (at least their typical use). So Python, Ruby, Java, C#,
JavaScript -- pick one -- without careful discipline, your code can
quickly devolve into a horrific mess. [2]

Erlang is no panacea -- there's some make-you-blind bad Erlang code
out there. But if you take its path of least resistance (i.e. stop
trying to make it look and act like Ruby) you get most of the
principles above without much effort. Or at least you have to work to
violate them.

> Is the answer Elixir?  It might be.  I'm certainly considering 'translating'
> Introducing Erlang.  I don't think a simple translation would be hard,
> though I suspect I'd have to restructure a fair amount.
>
> One way or another, it's not hard to imagine a world of people getting
> Erlang's benefits if we can make it seem friendlier.  There's little reason
> for Erlang to be the preserve only of people who write huge systems.

The reason I started using Erlang was a) I was curious and b) I ran
into a concurrency problem that would have cost considerably more time
and effort to solve directly in C/C++.

I don't know if the general audience of programmers will simply pick
up a new language because "it's healthy". I ought to adopt Clojure and
Haskell because they're great languages and I'd be a better programmer
for it. I haven't yet because I have a toolkit of languages (Erlang,
C, Python, bash) that will almost certainly solve anything I run into
(excluding platforms with language affinity like iOS, Android, etc.)

So if you can get by with Ruby, you use Ruby. Don't switch to Erlang,
which looks scary, just because it's web scale.

I'm almost inclined to think the real solution (assuming there's a
problem, and I do) is that instructors *teach* this stuff! Why the F
are students learning to program with *Java*? Start with Erlang -- a
simple, pragmatic, functional language -- and then introduce the
features from other languages and how to effectively manage them!

In any case -- and I'm not trying to be disagreeable, this is best
discussed over beer in a pub -- I don't think being developer friendly
or emotionally affirming or creativity enabling is a problem that
needs to be solve here.

> Thanks,

Thank you for calling this topic out!

Garrett

[1] Of course there are high quality C programs -- I just don't run
into them very often

[2] I use this term in a strictly scientific sense



More information about the erlang-questions mailing list