<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12-07-12 11:40 AM, Ian wrote:<br>
</div>
<blockquote cite="mid:4FFEF003.70605@gmail.com" type="cite">Hi CGS,
<br>
<br>
You are hearing things in my email that were not there when I
wrote it.
<br>
<br>
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.
<br>
<br>
Erlang the language is not the problem. The language is never the
problem. Once the tool chain is working......
<br>
<br>
But consider this. Rebar can't be installed in a standard Ubuntu
install of Erlang!!! WTF?
<br>
</blockquote>
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.<br>
<br>
Then people either create makefiles or have a README.md that
specifies how to build the project.<br>
<br>
As far as I know, the following ways to build projects are used:<br>
<br>
- Rebar in the repo<br>
- Rebar, where rebar isn't in the repo<br>
- Emakefiles<br>
- Sinan (usually not in the repo)<br>
- Makefiles<br>
<br>
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.<br>
<blockquote cite="mid:4FFEF003.70605@gmail.com" type="cite">
<br>
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.
<br>
</blockquote>
<br>
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 <i>while</i> keeping
LiveCDs available. An Erlang release was just too big, so they broke
it off in different sections that people usually assume are there.<br>
<br>
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.<br>
<br>
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.<br>
<br>
This lead to "compile it yourself and google in case of errors, it's
simpler" as a build policy.<br>
<blockquote cite="mid:4FFEF003.70605@gmail.com" type="cite">
<br>
Would you agree that giving newbies tools that are inadequate for
their needs, does not help them scale their learning curve?
<br>
</blockquote>
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.<br>
<br>
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!<br>
<br>
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. <br>
<br>
(I started working on tend (<a class="moz-txt-link-freetext" href="https://github.com/ferd/tend">https://github.com/ferd/tend</a>) 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).<br>
<blockquote cite="mid:4FFEF003.70605@gmail.com" type="cite">
<br>
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.
<br>
<br>
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.
<br>
<br>
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?
<br>
<br>
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.<br>
</blockquote>
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.<br>
<blockquote cite="mid:4FFEF003.70605@gmail.com" type="cite">
<br>
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.
<br>
</blockquote>
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<br>
<br>
- Someone who goes over a bunch of projects and documents them (how
boring!) <br>
- Each owner taking responsibility of that (Hard to do!)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 ;)<br>
<br>
Regards,<br>
Fred.<br>
</body>
</html>