Hacker News Reader

> What? How have you not heard of CPAN? There is not a single language in the world that can touch Perl's libraries.

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/

CPAN is much higher quality, though. For every Perl package that works and has unit tests and documentation, there are 10 node packages someone tried for a month to write, then gave up and left at 0.01 with no docs. Perl isn't sexy, but Perl diehards have written and published modules to do everything you can imagine.

The http://www.modulecounts.com/ site counts the number of distributions on CPAN, which probably is the closest measure for comparisons with number of projects given on PyPI, RubyGems, etc.

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

https://metacpan.org/recent

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.

Maven will not, by default, allow you to perform a release if there are any test failures. That seems like a better model, at least for a VM language - if something works on the release machine and not on the user's machine, you have bigger problems.

That's great to hear!

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?

No, the tests are run as part of the deploy. So before deploying a library, if the tests don't pass, the deploy fails.

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

Just to clarify, "deploy" in this sense means "upload to your organization's maven repository (or maven central)".

Ok cool, I understand.

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

Thanks again!

> Languages don't matter.

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.

I think you're missing George's point. Languages don't matter in isolation. It's the language plus the libraries plus the rest of the ecosystem, which he's calling the "platform".

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.)

I completely agree. As I wrote, libraries and other features of a platform do matter and of course you need to take those into account when deciding which language to use. It's always very specific to a given situation though, for example lack of "batteries included" libraries may not be a concern when choosing language to embed in your app (like Lua). But in general great language features and great platform features (for example working package manager) are both very important factors that you need to take into account when deciding on language(s) for your project.

> You have to have your head pretty far up your own ass to not see how much Common Lisp sucks. It's a language designed by committee, and it looks like it.

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.

Your comment is a bit confusing because you're basically explaining how Common Lisp was indeed a language designed by committee containing all sorts of compromises between competing vendors. That's what the OP was getting at.

I wasn't trying to contradict that. I was trying to indicste that failures in it are due to how much the terrain has changed. By and large the standardization process was successful, the failure is that there haven't been any revisions since (and likely won't be).

Sure, 25 years ago there were good reasons for the design compromises of Common Lisp. But that doesn't mean they make sense today, where "Windows or Unix" is pretty much the world, and there are any number of consistent, elegant languages that work on both.

> 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.

So we say the language is terrible because the world around it changed? Using Common Lisp may be inconvenient because the standard is out of date, that doesn't mean the design (or language) was a failure in a historical sense.

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.

I'm less interested in questions like "how much credit do the original designers of CL deserve?" and more interested in "what languages should I consider for my new project?". Is Dylan a viable option? If not, why not? "It's not because it inherits common lisp's non-interoperability" is then an interesting point.

> inherits common lisp's non-interoperability

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.

> between CL and the rest of the world is undeniably poor

Because CL is a language and not an implementation.

Many CL implementations have excellent interoperability capabilities.

> It's a language designed by committee, and it looks like it.

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 think a good reference for what people mean by "designed by committee" is to look at the reference spec for a language.

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.

Haskell was designed by committee, and it's exactly the opposite of the stereotype: it's a small language with orthogonal features and a clean syntax. The few "features" the language has, like list comprehensions and do notation, are defined by simple translations into the rest of the language.

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

And conversely, Ada was designed by one man, and if you weren't aware of that historical fact and just looked at the language spec, you'd swear it was the classic example of committee design. Fred Brooks' dictum that design should be done by a single mind, or at most two, is a guideline not a rule.

>Ada was designed by one man

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."

Right, but wasn't it structured as 'Ichbiah assisted by the others' rather than 'Ichbiah leading a committee by consensus'? In particular, iirc, there were some points at which the others almost unanimously disagreed with Ichbiah on some design decision and he overruled them and went ahead anyway.

Alternatively, look at R6RS[1]. 90 pages, including the index. That language is also designed by committee, and looks like it, too. An effective committee, that is.

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

Dylan was originally designed by committee back in the days when it was designed by people @ Apple, Harlequin and CMU.

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.

Common Lisp had different goals from Dylan. Common Lisp was designed as a powerful Lisp dialect, incorporating ideas from 20+ years back plus some new stuff. It was designed to be 'backwarts' compatible with Maclisp and its dialects.

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

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

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.

I am vaguely aware of how CL came to be, but was unaware of this report. I'll give it a read, thanks.

Scheme had a very shallow standard. It's written in a dense style and lacked basic stuff like error handling or an object system.

> 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...

> When a design succeeds, we say it was designed by the community; when it fails, by committee.

Extremely well said.

> You have to have your head pretty far up your own ass to not see how much Common Lisp sucks. It's a language designed by committee, and it looks like it.

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, ...).

> Languages don't matter. Platforms matter. APIs matter. Playing nicely with the rest of the world fucking matters. Common Lisp wouldn't.

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

Hmm, where is the ISO C++ standard to access the Windows file system?

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

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n394...

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

That's great. But it's POSIX, not native Windows.

the libraries abstract over most fs warts see Practical Common Lisp for an example

"Languages don't matter. Platforms matter. APIs matter. Playing nicely with the rest of the world fucking matters."

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.

> the Discourse peeps, who rejected eg PHP, and wrote it in their pet language, ignoring that no-one cares about language

Are you talking about Ruby/Rails?

The OP is being overly dismissive, but has a point -- there's a market for Ruby, but in terms of most of the use cases for online bulletin board software, both Rails and Postgres are much rarer than PHP and MySQL.

> no-one cares about language

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.

Read the whole post, everything sucks. It is Salinger + PK Dick + Vonnegut + Allan Watts.

Clojure is pragmatic in using jvm as its platform.