Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43678 > unrolled thread

The node.js Community is Quietly Changing the Face of Open Source

Back to article view | Back to comp.lang.python

Contents

  The node.js Community is Quietly Changing the Face of Open Source Rodrick Brown <rodrick.brown@gmail.com> - 2013-04-16 12:02 -0400
    Re: The node.js Community is Quietly Changing the Face of Open Source Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-17 09:16 +0000
      Re: The node.js Community is Quietly Changing the Face of Open Source Stefan Behnel <stefan_ml@behnel.de> - 2013-04-17 18:47 +0200

#43678 — The node.js Community is Quietly Changing the Face of Open Source

[Multipart message — attachments visible in raw view] — view raw

I came across this article which sums up some of the issues I have with
modern programming languages. I've never really looked at Javascript for
anything serious or Node itself but I found this article really
informational.

"The “Batteries included” philosophy of Python was definitely the right
approach during the mid 90’s and one of the reasons that I loved Python so
much; this was a time before modern package management, and before it was
easy to find and install community-created libraries.  Nowadays though I
think it’s counter-productive.  Developers in the community rarely want to
bother trying to compete with the standard library, so people are less
likely to try to write libraries that improve upon it."


http://caines.ca/blog/programming/the-node-js-community-is-quietly-changing-the-face-of-open-source/

[toc] | [next] | [standalone]

#43747

On Tue, 16 Apr 2013 12:02:01 -0400, Rodrick Brown wrote:

> I came across this article which sums up some of the issues I have with
> modern programming languages. I've never really looked at Javascript for
> anything serious or Node itself but I found this article really
> informational.
>
> "The “Batteries included” philosophy of Python was definitely the right
> approach during the mid 90’s and one of the reasons that I loved Python
> so much; this was a time before modern package management, and before it
> was easy to find and install community-created libraries.  Nowadays
> though I think it’s counter-productive.  Developers in the community
> rarely want to bother trying to compete with the standard library, so
> people are less likely to try to write libraries that improve upon it."

What of corporate users on locked-down boxes where installing software is 
either a firing offence, or simply cannot be done at all? Or they have to 
fill out long and tiresome forms requesting permission. Or students using 
shared machines, where even if you install something, it will be gone the 
next time you come in?

What of people who don't want the hassle of trolling through 7 different 
maths libraries looking for the "best" one to use, or who might not trust 
random packages found on the Internet by authors you know nothing about.

Or those who don't want to spend their time reading licences? With the 
Python standard library, you know you can use anything in that library 
without worrying about the licence. With third party libraries, you have 
to decide whether or not you are legally allowed to distribute that 
library, and if not, how do you install it for your customers?

There are all sorts of reasons why people might not want to *hunt and 
install* their own packages, starting with laziness and ending with "I 
like my job very much thank you, and I'd rather not get the sack". I 
think it shows astonishing privilege of the author to just assume that 
because he finds it easy to install third-party software, everybody must.

> http://caines.ca/blog/programming/the-node-js-community-is-quietly-
changing-the-face-of-open-source/


Just three sentences after telling us how the right URL library to use 
for Python is the third-party "requests" module, the author tells us that 
developers "rarely want to bother trying to compete with the standard 
library, so people are less likely to try to write libraries that improve 
upon it."

Like requests, huh?

He then compares node.js packages with Twitter:

"Just like the 140 character limit on twitter makes people “blog” more, 
the node.js community has a culture of publishing tiny modules that makes 
people more comfortable with publishing smaller packages, and so it 
happens vastly more often."

Yeah, because the vast bulk of 140-character tweets are something to 
aspire to. 

What matters is not how often people publish tiny packages that nobody 
uses. That's not a good measure of the health of a developer's culture. 
How many of those tiny packages are published, only to then languish in 
obscurity, lost and forgotten? How many are ever used by anyone other 
than their author?

ActiveState includes almost 4000 Python recipes:

http://code.activestate.com/recipes/langs/python/new/

and I would say that the great bulk of them are rubbish, or so 
specialised as to be of interest to very few people, or both. Or 
suffering from "NIH" syndrome. I see about 100 different recipes for 
implementing enums:"

http://code.activestate.com/search/recipes/#q=enums

I don't think that 100 different recipes for enums is a good measure of 
Python's health, and I don't think that hundreds of little tiny packages 
are a good measure of the health of node.js either.

If you look at the node.js site, the first thing that jumps out at me is 
that the culture encourages churning out packages rather than encouraging 
quality packages. The front page offers author recognition for being 
prolific, but not for writing good code. Good (or at least *popular*, 
which is not the same thing) packages get their name on the front page, 
but *authors* get their name on the front page by writing loads of 
packages regardless of quality.

The current most prolific author is Sindre Sorhus, and if you look at his 
list of packages, you will see a certain amount of replication. This is 
what happens when you reward people for quantity:


# generator-jasmine  Yeoman generator for Jasmine
# generator-webapp Default Yeoman generator for scaffolding out a front-
end web app
# generator-testacular Yeoman generator for Testacular
# generator-chromeapp Yeoman generator for Chrome App
# generator-angular Yeoman generator for AngularJS
# generator-mocha Yeoman generator for Mocha
# generator-bbb Yeoman generator for Backbone Boilerplate
# generator-backbone Yeoman generator for Backbone.js


https://npmjs.org/~sindresorhus


I wonder, how much copy-and-pasting between packages does he do?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43768

Steven D'Aprano, 17.04.2013 11:16:
> If you look at the node.js site, the first thing that jumps out at me is 
> that the culture encourages churning out packages rather than encouraging 
> quality packages. The front page offers author recognition for being 
> prolific, but not for writing good code. Good (or at least *popular*, 
> which is not the same thing) packages get their name on the front page, 
> but *authors* get their name on the front page by writing loads of 
> packages regardless of quality.
> 
> The current most prolific author is Sindre Sorhus, and if you look at his 
> list of packages, you will see a certain amount of replication. This is 
> what happens when you reward people for quantity:
> 
> 
> # generator-jasmine  Yeoman generator for Jasmine
> # generator-webapp Default Yeoman generator for scaffolding out a front-
> end web app
> # generator-testacular Yeoman generator for Testacular
> # generator-chromeapp Yeoman generator for Chrome App
> # generator-angular Yeoman generator for AngularJS
> # generator-mocha Yeoman generator for Mocha
> # generator-bbb Yeoman generator for Backbone Boilerplate
> # generator-backbone Yeoman generator for Backbone.js
> 
> 
> https://npmjs.org/~sindresorhus
> 
> I wonder, how much copy-and-pasting between packages does he do?

It's possible that the answer is "none", and that you actually need to
install all of his packages in order to make use of one.

Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web