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

Tue Feb 18 09:34:11 CET 2014

Thank you Gordon,The absence of a decent package manager as disturbed me
for a long time.

I'd like to add a few thoughts I have on the matter.

Excuse the rant - I feel rather strongly about this. This is written great
haste.
I have to give a lecture in 20 minutes.

Here are some things I'd like to see:

1) A decent standardized Manifest.

A manifest is just a list of files and a short description.  It also
has copyright and licensing information, and possible authentication
checksums and proof signatures.

Nothing fancy - but it needs a standard.

I don't feel strong about the format or the content. but it MUST have
a version number :-)

<rant_mode_on banging_keyboard="true">

2) Packages should NOT be unpacked on the destination machine.

Unpacking a package BREAKS an abstraction boundary. I feel VERY
STRONGLY about this.  I hate unpacking things and finding that they
scatter thousands of files all over my disk.

Here's a radical proposal. The top level package should be a PDF file.

In 2001 ago I wrote this

http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think
about it.

This a simple program that packs a file inside a PDF container. It still
works.
It seems like the one line description on my sics web page did not cause a
stir of
interest in the program (which I thought was a fun idea) so I'll now
publicize the idea a bit more.

<aside>

  I guess one line of publicity in 2001 on my web site did not cause the
world to beat
   a path to my door. So not after 13 years I'll post a reminder

  (was that right Garrett? - banging the old publicity drum hard now :-)

   Note: it would be *easy* to change the code loader to LOAD CODE FROM THE
PDF FILE.
</aside>

Q: Why should the top level package be a PDF file?
A: Because the *first* thing I want to do is read the documentation.
   I won't even look at a program that has no documentation - it's a waste
of time.

Q: Why should the top level package not be unpacked?
A: Because it breaks an abstraction boundary, make it difficult to delete
things etc.

I don't have to unpack a jar file to execute the program in it. I
don't have to unpack a .exe file to execute it so WHY IN THE NAME OF
THE GREAT SLIMY THING THAT LIVES UNDER STONES should I have to unpack
an Erlang package to execute the code in it?

When I want to use say (cowboy) I just want to execute the code - I
don't want to see all the details of what going on inside the program -
I don't want to know that it is made of loads of modules - I want to
hide the details - this is called ABSTRACTION.

They tell me that they teach OO programming these days - I thought the idea
of an object
was to HIDE THE DETAILS OF THE OBJECT INSIDE THE OBJECT - so why do
people who have been brought up on OO programming insist on writing
programs that scatter files all over my disk? Hide your mess in a
single container. Pleeeeeese.

Q: How do I install a program?
A: Put the PDF in the directory ${HOME}/.erlang_programs/

Q: How do I delete the program?
A: Remove a single file from ${HOME}/.erlang_programs/

Q: How do I develop the program?
A: Unpack the PDF file *somewhere else*

3) How should we distribute programs?

Why not just use Bit Torrent? - we can self-seed our code, and seed
code we approve of That way popular code will be multiply seeded and
unpopular code with wither and die.

We could use Jespers Bit torrent client and adapt it a bit so it knows
about Erlang packages.

To do this we need

    a) Trackers (easy)
    b) an Index (needs a publishing protocol)
    c) clients

Erlang solutions etc. can trackers.

The code can be ANYWHERE YOU FEEL LIKE and not on github.

Putting stuff on github is for collaboration purposes, not for distributing
code.
Use BitTorrent for this.

</rant_mode_off>

Cheers

/Joe

On Mon, Feb 17, 2014 at 11:33 PM, Gordon Guthrie <gordon@REDACTED> wrote:

> This is what I sent to Francesco
>
>
> ****************************************************************************************
>
> *Building The Erlang Community*
>
> *Background*
>
> Erlang has long lacked a solid community core to act as a place where
> users can discover existing modules and include them in their projects.
>
> *rebar *now provides the standard mechanism to include external
> dependencies - this proposal is about making erldocs the standard place to
> discover community contributions.
>
> *Proposal 1*
>
> The proposal is that people who publish open source Erlang modules on
> GitHub be able to have them listed on erldocs.
>
> The process would be two part:
>
>    -
>
>    commit a page called *ERLDOCS.terms* to github in the root next to
>    *README.md*
>    -
>
>    submit the URL to a page on erldocs
>    -
>
>    erldocs would sook the github page into a community section
>
>
>  The structure of the *ERLDOCS.terms* file is simple tagged tuples,
> something like:
>
> *{name, "Starling"}.*
>
> *{license, "EPL"}.*
>
> *{description, "Unicode support for Erlang"}.*
>
> *{details, "A C-Port wrapped around the ICU library for unicode"}.*
>
> *{status, "production"}. % alpha | beta | production*
>
> *{rebar, {version, "1"}, {starling, {git, "git://**github.com/hypernumbers/starling.git
> <http://github.com/hypernumbers/starling.git>**","master"}}}.*
>
> *Proposal 2*
>
> Dale Harvey originally intended that erldocs should include the ability
> for members of the community to annotate the official documents with
> examples, links to tutorials etc, etc.
>
> erldocs be so extended (by use of Disqus or other standard commenting
> systems)
>
> *Requirements For Success*
>
> Erldocs 'failed' last time out because the OTP team changed the way
> documents were generated, and Dale Harvey moved on from an Erlang shop to
> Mozilla.
>
> In order for this to work Erlang Solutions has to commit to:
>
>    -
>
>    erldocs being the official community repository for Erlang
>    documentation - linked to directly from *erlang.org
>    <http://erlang.org/>*
>    -
>
>    production of these documents needs to be integrated into the OTP
>    Team's release schedule
>
> *Modalities*
>
> If Erlang Solutions so agree the next stage would be to approach a number
> of suppliers of top-notch Erlang open source and sign them up for launch.
> My working list would be:
>
>    -
>
>    Erlang Solutions
>    -
>
>    Basho
>    -
>
>    Erlware
>    -
>
>    Mats Cronquist
>    -
>
>    Richard Carlsson
>    -
>
>    Yaws
>    -
>
>    Mochiweb
>    -
>
>    Nitrogen
>    -
>
>    Cowboy
>    -
>
>    Web Machine
>    -
>
>    Hypernumbers
>
>
>  There would need to be consultation with the launch group regarding the
> structure and elements of the term file.
>
> Once they were onboard and the production cycle had been tested - an open
> launch on the mailing list.
>
>
> ****************************************************************************************
>
> The key point is that a community is only a real community if you choose
> to join it. I was 'joined' to the Agner community (and there have been
> other attempts, Erlware, CEAN, etc) but they don't stick.
>
> Gordon
>
>
> On 17 February 2014 22:28, Mark Allen <mallen@REDACTED> wrote:
>
>> On 2/17/14 4:21 PM, "Garrett Smith" <g@REDACTED> wrote:
>> >> On 2/17/14 1:51 PM, "Vixo" <gordon@REDACTED> wrote:
>> >>>My suggestion would be a manifest file of Erlang terms at the root
>> level
>> >>>of a GitHub page (they will *all* be on GitHub) that can be polled and
>> >>>turned into a static site. The logical thing to do would be combine
>> thus
>> >>>with the revived erldocs site IMHO (as I have said to Francesco)
>>
>> >Does this require that all of github be crawled?
>>
>> No. I'm pretty sure we can segment the crawl to only projects with some X
>> threshold of Erlang. (I'll have a slice without so much rat in it. [0])
>>
>> >Would a github based index make sense? Complete with a liberal pull
>> >request policy?
>>
>> Most likely, yes, using github pages with a nice custom domain would be a
>> Good Thing for this type of project.  The code to do the crawl and build
>> the index should be open source too, imo.
>>
>> Mark
>>
>> [0]:
>>
>> http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program
>> me_.5B3.03.5D
>>
>>
>
>
> --
> ---
> Gordon Guthrie
> CEO vixo.com
> @gordonguthrie
> +44 (0) 7776 251669 (in Bonnie Scotland!)
>
> vixo is made in Scotland from electrons
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140218/5cb8fb32/attachment.htm>