[erlang-questions] Looking for slides of a lightning talk
Thu Jul 12 19:44:31 CEST 2012
On 12-07-12 11:40 AM, Ian wrote:
> Hi CGS,
> You are hearing things in my email that were not there when I wrote it.
> I was reporting my experience, not blaming Erlang for anything. My
> experience is that the learning curve for the Erlang tools (coupled
> unfortunately with learning the Linux environment) was extremely steep
> - and ended up with me getting stuck because the tools failed to do
> what they claimed (in multiple ways) before I had the skills or
> knowledge to fix them.
> Erlang the language is not the problem. The language is never the
> problem. Once the tool chain is working......
> But consider this. Rebar can't be installed in a standard Ubuntu
> install of Erlang!!! WTF?
Projects tend to include their own copy of rebar within their own repos.
There are a few that don't do it and do assume a globally installed
rebar, but I think they're not the majority of repos.
Then people either create makefiles or have a README.md that specifies
how to build the project.
As far as I know, the following ways to build projects are used:
- Rebar in the repo
- Rebar, where rebar isn't in the repo
- Sinan (usually not in the repo)
Moreover, there is a strong culture of getting stuff from source and
compiling it ourselves. There is no big central library of precompiled
code, and frankly, I'm not sure who would want to maintain one that
people would use. There's always the issue of "nobody uses it so nobody
is going to use it" to go over. Rebar made itself a good spot because it
didn't require anyone to have it installed. It had a little
self-executable (as long as Erlang is installed, see escript), and so
you needed no one's support to get it going.
> Would you agree that that means at least one of those installs is
> inadequate for my needs? Its inadequate for anyone who wishes to use
> rebar and Erlang on Ubuntu/Debian.
I don't exactly remembers who maintains the Ubuntu repositories, but
historically, this has been a problem since they wanted to include
CouchDB as part of the default offering /while/ keeping LiveCDs
available. An Erlang release was just too big, so they broke it off in
different sections that people usually assume are there.
Regarding Debian, I haven't looked at it much since they took R14A (or
was it R13A?) and declared it stable; that version is a beta version,
and because of this (I believe, either this or github), the OTP team at
Ericsson stopped distributing the source for A versions on erlang.org.
It's been a problem of maintainers; Distros tend to do things one way,
and Erlang lives within its own world that sometimes clashes with it.
From what I know, package maintainers for distros tended to be more
familiar with distros than they were with Erlang, but any maintainer can
feel free to correct me.
This lead to "compile it yourself and google in case of errors, it's
simpler" as a build policy.
> Would you agree that giving newbies tools that are inadequate for
> their needs, does not help them scale their learning curve?
Agreed. I wrote Learn You Some Erlang and it suprises me that in order
to get the structure I wanted, I had to wait more than 5 chapters before
showing how to run something from the command line. Hello world as a
self-executable is quite something if you don't use escripts.
The question I came up with while writing LYSE is "how can we make
things easier?" Erlang is complex in itself. People who used it for
years tend not to know how the ERL_LIBS variable works (or how it
exists) when it's doing something as elementary as finding where
We have build tools that are somewhat decent enough once their
environment is ready. You're new to Erlang, if you can send me a list of
the steps you took, I'll keep them in note.
(I started working on tend (https://github.com/ferd/tend) with a guy
nicknamed orbitz for Spawnfest, and I plan to possibly use it as a tool
to download libraries of applications (yes, another one), so help in how
to make things easier is always wanted).
> This is not meant as a criticism of the work people have done. Its a
> very hard problem, and I don't think there is an easy solution.
> PHP isn't there yet. PEAR is not widely used. The comments added to
> the manual are very helpful. PHP the language is astonishingly
> Python boasts "batteries included". Whatever you want to do in Python,
> there are usually 6 modules that claim to do it - all poorly
> documented, some buggy. So do you spend your time investigating them,
> or writing a 7th that you know will do what you want?
> Experienced people have forgotten the misunderstandings they had as
> newbies - or they had an experienced person to guide them - so they
> are genuinely puzzled by the problems newbies face. The newbies can't
> help: they don't know what they don't know. Few technical people can
> write well, and all are busy with their projects. The result is a
> distinct lack of excellent, current documentation of the tools that
> can help newbies start to use Erlang.
As someone who wrote some technical documentation (I am not a technical
writer, however), the biggest issue I faced was that Erlang is in a kind
of perpetual renewal state when it comes to build tools. Nobody likes
them absolutely, everyone has a favorite (and I'm not helping!), and
things change so fast it would be very risky to take lots of time to
write something that might be invalid in a few weeks or months.
> It comes, slowly, with maturity and stability. Erlang the language is
> well documented. Its the docs for the supporting cast that is spotty.
> Which is a shame.
Erlang/OTP has pretty good docs. There is, however, very little doc when
it comes to the code the community produces. I'm not sure how to change
that without either having
- Someone who goes over a bunch of projects and documents them (how
- Each owner taking responsibility of that (Hard to do!)
Earlier this week, Jesper Louis Andersen (jlouis) used one of the
libraries a coworker developed at work. He simply took the undocumented
code, took a bit of time after figuring it out, and documented how to
use it, sent a pull request, and within the hour, it was accepted.
I think this is a very good attitude to take. If someone wrote us a
library and didn't have the time to document it, basic documentation
could be a decent 'pay it back' measure to be given to the authors when
we use their code. It's saving us time using the library, let's take a
fraction of the time it saved us to pay back with some docs.
Projects like rebar would have books written on it at this point if it
were the case. I'd do it, but by now I'm getting pretty tired about
writing documentation ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions