[erlang-questions] Is erlang a web language?

[Peter Sabaini]

On Sunday 15 February 2009 12:56:19 Joe Armstrong wrote:
> This is my take on the matter.
>
> To start with I don't think one distribution scheme or library will
> ever work - the work
> making it consistent is colossal.

Yet rubygems or PyPI seem to work out quite well.

To me this is mostly about findability and having a uniform interface for meta 
data -- version numbers, homepage, release history etc., this makes a huge 
difference in choosing a lib.

> I rather like what's happened in the javascript world.
>
> Here there is a core-language, and alternative sets of rather-good
> libraries.
>
> To me a good library has
>
>      - a book (or books) -
>      - community who contribute to the library
>      - a unifying principle
>      - a set of applications that use the library

IMHO this rather depends on the library -- a small library that does one thing 
well and has only a small interface won't need a whole book for documentation.

> The javascript jquery and protoype libraries live up these criteria.
>
> After I finished the erlang book I started writing a library and a number
> of applications based on the library. My plan is:
>
>      a) write a base library and applications
>      b) open source it and invite community participial
>      c) improve quality of library through participation
>      d) write a book describing the library
>
> I'm in the middle of a) - I now have a dilemma, should I release now or
> later.
>
> advantages: early feedback
> disadvantages: quality problems - it's in a bit of a mess, so it gets
> a bad reputation.
>
> Or wait a year or so:
>
> advantages: higher quality of release
> disadvantage: loose user feedback
>
> Do you want software "early and buggy, badly documented" or
> "late and better documented, higher quality"

The classical "Release Early, Release Often" is still a valid approach I 
think. As long as it clearly says on the box (with big bold letters) if 
something is alpha/beta/release quality you won't get a bad reputation. Or 
only from people who do not read :-)

Just my 0.02eurocent...

peter.



> I would welcome some feedback here
>
> /Joe Armstrong
>
> 2009/2/15 Edwin Fine <erlang-questions_efine@REDACTED>:
> > On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <watson.timothy@REDACTED>
> >
> > wrote:
> >> > I am using sinan/faxien exclusively, and have installed and maintained
> >> > four
> >> > Erlang production systems with them. There were some teething issues,
> >> > some
> >>
> >> This is interesting - I also started out with good feelings about
> >> sinan/faxien, but they appear to redistribute the core OTP libraries
> >> which is anathema where I work.
> >
> > Martin & Eric can speak for themselves, but my point of view is that,
> > well, they don't really redistribute them as such. They are forced to
> > build them using their own tools and put them in their WebDAV repository
> > because (a) The OTP team doesn't support such a repository, and (b) they
> > have to make minor tweaks to the add their metadata, which is necessary
> > for the distribution mechanism. The metadata doesn't exist - or, in the
> > case of .app files, sometimes doesn't quite fit in - in the OTP
> > distribution. I am pretty (99%) sure there is no fiddling with the source
> > code at all, it's just an alternative way to build it, no more suspicious
> > than building OTP from the tarball. If there was a way to build OTP with
> > their (Erlware) tools in a 100% automated way, then anyone could do it,
> > but they are not quite there yet (as far as I know). So that is indeed a
> > sticking point, I can see.
> >
> >> We're simply not allowed (by law) to
> >> run code on "some version" of kernel/stdlib/etc that didn't come from
> >> a verified (official) sources, even if it did in reality (if you see
> >> what I mean). This is an issue of regulatory compliance, so we're
> >> stuck and can't use the tools, which are (I agree) very nice bar some
> >> minor usability issues. I suspect this puts a lot of people off - it's
> >> not as maven downloads and installs the JDK for you is it, and for
> >> good reason - I'd be surprised if that many people actually wanted
> >> this.
> >>
> >> Clearly there are mixed opinions about whether a repository for
> >> publishing applications and a distributed build system that can
> >> consume code from public/private repos, is a good approach. That's to
> >> be expected, but this idea of redistributing "Erlang itself" is
> >> another thing altogether. It seems like trying to force too many new
> >> ideas at once, and I suspect this is a big part of the problem.
> >
> > Again, I believe they don't WANT to redistribute Erlang. It's a huge pain
> > in the butt to have to tweak new Erlang releases to build with their
> > toolset, and it's not really the fault of their toolset, it's just minor
> > inconsistencies here and there that cause issues. If they could get it
> > right that anyone could build Erlang itself using Sinan, and then put it
> > in their own private Erlware repo with Faxien, these objections would
> > largely go away.
> >
> > If you look at what Ruby has managed to achieve with Gems, and (I think)
> > Python with "eggs", it is quite reasonable to expect that we should be
> > able to distribute our own Erlang apps in a pre-built form in a way that
> > makes it really easy to update. I use this mechanism to update production
> > servers in a number of different countries, and the previous way I did it
> > was just horrible. It's so much easier for me just to log into the remote
> > server, type in "faxien upgrade-release myapp", maybe tweak the
> > sys.config, and then restart the application (I don't need hot code
> > update yet). The sad thing is that Erlware is *so* close to being really
> > great, and is held back mostly because the authors are so busy actually
> > earning a living that they don't have enough time to devote to ironing
> > out the wrinkles.
> >
> > My great hope is that the Erlang/OTP team will see enough merit in this
> > approach to make this a standard distribution mechanism, but I don't hold
> > out much hope (not because the team is unreasonable or anything, but
> > because of the overhead of supporting builds across many hardware
> > platforms and version within the platforms.) An easier and even better
> > thing would be if they actually used Erlware to build the Erlang source
> > code; then we could all build it with Erlware and the main objection
> > would be solved. Also, they could put some resources on it to help with
> > the wrinkles.
> >
> > Just dreaming ;)
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090215/dd035b5b/attachment.bin>