[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:21:10 CET 2014

On Tue, Feb 18, 2014 at 01:13:11PM +0100, Joe Armstrong 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.
> 
>

Then you mustn't use the vast, vast majority of Erlang projects.
> 
> 
> /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
> >
> >
> >

> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140218/9b921883/attachment.bin>