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

Dmitry Kolesnikov dmkolesnikov@REDACTED
Tue Feb 18 15:48:33 CET 2014 

Hello,

I would not mix documentation and binaries as a single PDF package. You need documentation while discovering packages, developing agains it's API. At different stages, you need different documentation such package bio, API, operation manual etc. Git Page is an interesting concept to expose documentation and code within same repository... 

Stand alone package is handy for production deployment but I'd like to have ability to inspect source code while developing.


Best Regards,
Dmitry
>-|-|-(*>

> On 18 Feb 2014, at 14:13, Joe Armstrong <erlang@REDACTED> wrote:
> 
> 
> 
> 
>> 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","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
>>>> 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
> 
> _______________________________________________
> 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/81219ef0/attachment.htm>

More information about the erlang-questions mailing list