couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Why CouchDB uses JavaScript (Was: make all this extra C optionnal)
Date Sat, 21 Sep 2013 09:48:13 GMT
On Fri, Sep 20, 2013 at 4:56 PM, Jan Lehnardt <jan@apache.org> wrote:

>
> On Sep 19, 2013, at 11:51 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>
> > Hi,
> >
> > I am thinking to make all this extra C optional in couchdb. By extra C I
> > mean:
> >
> > - snappy compression
> > - couch compare function using ICU
> > - JS views
> > - JSON encoding
> >
> > Basically anything that is not included in the erlang standard library or
> > not in Erlang. The reason for that is to allow a simple distribution on
> > different platforms or vms things like erlangonxen. Also it would
> improve a
> > lot the way we can upgrade a full release or change a module live.
> >
> > First one is easy, the second I don't know I guess we can have a more
> > simpler binary comparison is possible or maybe better providing a pure
> > erlang implementation of it using ux [1] wich is probably enough faster
> for
> > our need (we only require to compare ids or keys).
> >
> > We mostly have JS because it's easy to handle for an end-developer and
> also
> > trendy among some circles.
>
> I massively support moving to a tiny Erlang-only core for CouchDB with
> additional features on the side.
>
> We need to differentiate between what the core of CouchDB is and what the
> distribution we ship to end users includes. I would not feel comfortable
> shipping a major version of CouchDB in the future that doesn’t include
> JavaScript powered views. Instead, I think it should be very simple for
> us to ship, or for users to compile, a version of CouchDB that is just
> the core, or just the core and only the extensions they are interested
> in, not the ones that we think are a good default for everyone (someone
> might want to have a CouchDB distribution without a replicator and that
> should be totally easy to set up).
>
> (Not saying it was suggested that CouchDB-core should be the default
>  distribution, I just want to point out that it is an important
>  distinction to make)
>
> Why do I think we should not ship a CouchDB version without JavaScript?
> This is a direct reaction to “trendy among some circles”. JavaScript is
> by far the most deployed, the most programmed and the most understood
> programming language in the world and it is only gaining at this point.
> To pretend that it is a niche phenomenon is ignoring the massive
> advantages we gain from shipping JavaScript support by default. Nearly
> everyone knows at least enough JavaScript to get something done in
> CouchDB, that is a benefit that I don’t see go away any time soon and
> I think it is *very* important for us to keep this going.
>
> I am very eager to support JS alternatives, and I am #1 in longing for
> a neat DSL (hopefully done on top of Erlang or Elexir) that allows us
> to define views and other useful things in a neat declarative way. But
> we don’t have that yet, and for when we do, I still thing enough use
> cases that require a bona-fide programming language and the best one
> for that in today’s world and the near future is JavaScript. I’m not
> saying JavaScript is the best programming language, but given what we
> need a programming language for, JavaScript is the best option we have.
> That’s why I think Apache CouchDB should ship with a JavaScript
> interpreter by default for the foreseeable future.
>
> I also very much support the idea of a pure-Erlang core for the users
> that need that, but we need to make sure we do the right thing for most
> of our end users in a way that doesn’t disadvantage the rest and I
> think the scenario of a small core as suggested + addons that make up
> a default distribution with the possibility of making custom
> distributions easily gets us exactly that.
>
> Best
> Jan
> --
>
>
We can disapprove or not about the the popularity of Javascript neither if
it's really understood by most or if it is the best programming language.
It really depends in which branch you are working in computer industry:
web, game, science, ...  or which kind of company. Each have their winner,
and for example  in the game industry, javascript is only starting to come
in, some are using different scripting languages...  It is also depends on
what you consider programming is, if you value the readability or not, such
things. Only the future will tell us, which kind of programming will win,
even if some are trying hard to remove the choice these days by imposing a
language in their UI or their devices.

Anyway I don't really care if Apache CouchDB has to be shipped with
Javascript support or not. The point here is more here to have a way to
disable it, to make it optional so people can deploy and upgrade it more
easily according their needs. And I don't see any reason for now to not
ship Apache CouchDB with javascript until it can be made optional during
the build.

- benoit



>
> > But i think we could provide here another
> > default. That can be elixir [2] or lua using luerl module [3]. The second
> > one may be the easier since it is also provide for free the sandbox we
> are
> > supposed to have in JS. Not sure it is easy to do with elixir.
> >
> >
> > Thoughts?
> >
> > - benoit
> >
> > [1] https://github.com/erlang-unicode/ux
> > [2] http://elixir-lang.org/
> > [3] https://github.com/rvirding/luerl
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message