[erlang-questions] Looking for slides of a lightning talk

[Fred Hebert]

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
- Emakefiles
- Sinan (usually not in the repo)
- Makefiles

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 
libraries are!

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 
> inconsistent.
>
> 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 
boring!)
- 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 ;)

Regards,
Fred.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120712/27ddc5e1/attachment.htm>