That's a really outdated meme. CPAN is small, pretty much every language you hear about regularly has a larger package space than CPAN. Even Go's package space is bigger than CPAN's. JS and Java each have package spaces roughly 3x CPAN's size.

http://www.modulecounts.com/

However GoDoc seems to be showing number of package namespaces. If so this would be more comparable to the module count on CPAN (see http://www.cpan.org/)

So at this point in time we have:

  GoDoc:         36,497
  CPAN dists:    30,216 
  CPAN modules: 137,603

There are a couple of CPAN module installers, and every one of them, by default, will not install the target module if there are any test failures.

Honest question: are there any other languages that do that? I last looked a few years ago, and it didn't seem to be the case.

I'm not too strong on Java; does what you're saying imply that some/all/most of the freely available Java 'modules' or 'packages' that are built with Maven will end up running and passing associated test suites in most all of the organizations that end up using the code in question?

However, the artifact that actually gets deployed is a .jar file containing .class files. Users of libraries don't rebuild the libraries.

So would you guess there'd be wide-spread 'deploy-time' test coverage across the Java ecosystem?

Thanks again!

Bullshit.

Languages DO matter. Language features matter, too. Even syntax matters, although not that much.

It's easy to get trapped in "languages don't matter" attitude if you know a couple languages. The perspective changes drastically with mastery - being able to use a language to its fullest, as opposed to just using it - and with dozens more of learned languages.

A language is your baseline, a starting point for building things. How you build API, how you interact with outside world, how you accomplish common tasks depends on a language and language features. And it gets even more important as you climb the abstraction ladder. For example, at language level Scheme offers call/cc. You may say it doesn't matter, as it's just a language feature. But take a look at Racket continuation-based web server - it's an impressive piece of work which solves a certain problem really well and is almost impossible to implement in some other languages (you don't need continuations specifically to implement this, there are other features which would enable it). At a language level Lua offers coroutines, which in itself is not very impressive. But take a look at OpenResty: you can write code which looks perfectly normal and synchronous (no callback etc.) while still fitting inside of async by nature Nginx.

Anyway, thing you mention, like APIs, do matter too, but language features are equally important. Don't dismiss them because you superficially know a few languages; rather learn some of them in depth and build real world things with them and I'm 97% sure you'll see how language features matter.

If you have this language with these great features, but it has lousy libraries and therefore you have to write a bunch more stuff yourself, you need to weigh that against the great features when deciding whether to use that language. Just having the great features isn't enough. (In fact, this is a big part of how Java conquered a big chunk of the world. As a language, it's kind of a yawn. But the library is like Barbie - it has everything.)

Erh, no. You don't seem to have any historical insight into how common lisp came to be. (Or maybe you do have historical insight and are just being willfully ignorant).

It is a language designed by a set of companies and institutions compromising 25 years ago. Companies and institutions that had radically different operating systems and hardware, it wasn't a matter of writing software for a machine that ran either 'Windows or Unix.' You had to support the lisp machine vendors and a variety of mainframes/minicomputers. Emphasis on 'Common.' The theoretical possibility was that you could write a program on a MacIvory and then run it on your Symbolics Machine, ThinkingMachines machine, Unix Machine, Windows machine, PDP-11, Dandelion, DEC Alpha etc...

Go write a C (or Python for that matter) program that lets you access the file-system port-ably on a huge variety of operating systems using only the C standard. I suspect it will be difficult.

Anyway, you couldn't be any more wrong. You've limited the 'entire world' to essentially two similar platforms, one of which (Windows) isn't really that well supported.

The whole point is that it tried really, really hard to satisfy the entire lisp world, which included a number the larger players who were put out of business by Moore's law and cheap generic hardware rapidly outpacing expensive special purpose hardware.

All this said, Common Lisp (and Scheme, and it's implementations) have features that the general programming community is still rediscovering 30 years later. Dismissing it as something that sucks because the people involved didn't try hard enough is incredibly myopic.

tl;dr: Nu-uh.

> All this said, Common Lisp (and Scheme, and it's implementations) have features that the general programming community is still rediscovering 30 years later.

A language is more than an accumulation of features. It doesn't matter how advanced an implementation is if it's not actually pleasant to program in.

> Dismissing it as something that sucks because the people involved didn't try hard enough is incredibly myopic.

I don't think anyone's saying they didn't try hard enough. But interop between CL and the rest of the world is undeniably poor - and this largely seems to be a deliberate choice by the CL community - and it's not much of a stretch to say that its unpopularity is a result of this.

I just think this whole argument is basically a straw man. Comparing something well specified that hasn't changed is 30 years to an entire class of hand wavy 'better languages' isn't an apples to apples comparison, and is, frankly, a dumb waste of time.

Yeah, but that would be bullshit to assume. I use for example LispWorks (commercial, proprietary) and Clozure CL (free, open source) on my Mac. Both have excellent interoperability with C and Unix. Both have a native Cocoa interface to the Mac.

Because CL is a language and not an implementation.

Many CL implementations have excellent interoperability capabilities.

This means nothing. When a design succeeds, we say it was designed by the community; when it fails, by committee. You can produce examples for any language: In Common Lisp the committee that designed it and the community of previous Lisp users that backed it. For Python, the community of users and Guidos' mailing list pals. There is nothing inherently superior or inferior about design by community or committee, respectively.

I remember picking up the Common Lisp reference book in my college library. It was one of the thickest books in the entire CS section. Obviously much thicker than any books on Scheme, but even on the same level as "The C++ Programming Language". And the latter spends a lot more time explaining things than the Lisp book did.

CL is a huge and complex language, and I'm still not sure why there are 80 different ways to loop. It's a confusing language, with not nearly as much orthogonality as it could have.

http://www.haskell.org/onlinereport/

http://cs.fit.edu/~ryan/ada/ada-hist.html

"The Ada design team was led by Jean D. Ichbiah and has included Berned Krieg-Bruechner, Brain A. Wichmann, Henry F. Ledgard, Jean-Cluade Heliard, Jean-Loup Gailly, Jean-Ryanmond Abrial, John G. P. Barnes, Mike Woodger, Olivier Roubine, Paul N. Hilfinger, and Robert Firth."

> I'm still not sure why there are 80 different ways to loop

There are many ways to loop, because users found those useful. Lisp by tradition is not telling the developers what they have to use. It's the opposite: it gives the developers various degrees of freedom to shape the language (from macros, read macros, ... to the MOP).

You could have easily removed something like DOLIST from the standard. But why? Software before and after the standard will still use it. How about MAP ? Remove it! But wait, people have used it already and will still use it...

Lisp languages are ball-of-mud languages where users can add their own control structures.

If you look at Scheme, they have added all this and more with SRFIs. Now you get a language, whose implementations support a minimal language and each will implement some subset or superset of SRFIs...

And many of the people involved with that were also involved with the Common Lisp standardization (like David Moon, Scott Fahlman, etc).

Common Lisp is a pretty interesting example, but due to the politics of the various companies involved, the vast amounts of code in each of the various Lisps, and so on, I don't think it is a fair reflection on "designed by committee". It is just what that committee was able to design given the constraints imposed upon them.

In many ways, Dylan was a stripped down and much more minimal Common Lisp, but with aspects of Scheme as well. But Dylan was designed from a green field, while Common Lisp was designed with a number of existing Lisps in mind that each had a stake.

Dylan was designed as a new language (compatible with nothing) for application development and delivery for small machines.

[1]: http://www.r6rs.org/final/r6rs.pdf

Please ignore if you're asking rhetorically. But there are reasons why it was put together in kind of a wild political dash. See: (https://groups.google.com/d/msg/comp.lang.lisp/Llmnxk2SYUk/y...) and (http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf)

An evolving, used platform which was (suddenly?) pressured to freeze.

Extremely well said.

The original design was by four people. Common Lisp does not look worse or better than the Lisp's it was designed to improve on (Maclisp, Lisp Machine Lisp, NIL, ...) and the Lisps it made mostly obsolete (Portable Standard Lisp, Interlisp, ...).

this. playing with CL inside CL is fun and nice. As soon as you try to interface with the outside world, and actually do almost anything you run into trouble. I mean an FS api that was designed before we solidified on hierarchical filesystems? Lisp does not play nice or well or easily with the outside environment it is running on. (in my experience)

it can be an ugly language, but if it has all the libraries, then you can get so much more done so much quicker with so much work done for you, people will go there.

Again, some little progress has started with things like quicklisp finally starting to provide a better (or first proper) package management system for CL like most newer languages have all had, but still. little and late. But given time and work maybe resuscitateable. We'll see

If you were using say, Allegro CL on Windows, I doubt you had any difficulties accessing the file system.

Not finalized yet, but soon: https://isocpp.org/std/status

(It is basically a standardization of boost::filesystem)

Here are the MSDN docs: http://msdn.microsoft.com/en-CA/library/hh874694.aspx

Nice, I like that.

Reminds me of the Discourse peeps, who rejected eg PHP, and wrote it in their pet language, ignoring that no-one cares about language, and finding the problem that their platform is so difficult to install and use, that no-one uses their software.

Yeah, why should users ever care about language? Users generally don't know what the heck this "language" thing is. At least if it's not French, English, Chinese or something like that.

Now, for developers, not caring about a language they use is very short-sighted, to say the least.

Are you talking about Ruby/Rails?