[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 13:13:11 CET 2014

On Tue, Feb 18, 2014 at 9:45 AM, Dmitry Kolesnikov
<dmitry@REDACTED>wrote:

> Hello,
>
> 1) A decent standardized Manifest.
>
> The app file by itself is a good place to be manifest.
> the env section might be expanded with following keys:
>  * url
>  * signature
>  * ...
>
> 2) Packages should NOT be unpacked on the destination machine.
>
>
> What is wrong with erlang archive files?
>

I already said this, 27 lines after the point 2) heading.

I'll repeat this:

            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.

/Joe

>
> - Dmitry
>
> On 18 Feb 2014, at 10:34, Joe Armstrong <erlang@REDACTED> wrote:
>
> 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
>>
>>
> _______________________________________________
> 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/7a3ccd1b/attachment.htm>