[zbentley]

I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box".

And that's not even a statement about how many ways there are to the same/similar things things; these features all are intended to facilitate different stuff. I think it is the biggest language I've ever programmed in, fighting for top spot with C++.

I think core-language-feature counts are something it's better to have in moderation. JavaScript of ~2010 was far too small a language, so it had crazy library/cargo-cult utility bloat. Lisp is somewhat similar: it's elegance in its small size and simplicity, but that results in a lot of beginners (re)writing a lot of unnecessary code. Perl and C++ have too many core-language features; everything else is somewhere in the middle.

...and all that is without even getting into some of the insane language extensions you can find in third-party libraries. There's an on-after-module-load hook someone wrote that's implemented in terms of a syntax extension to the language, that isn't quite an operator or a statement. There's a coroutine library which is written mostly inside to the fatal-killsignal core dump handler I think (or something similar). And the list goes on.

[kazinator]

> I think core-language-feature counts are something it's better to have in moderation.

If an app needs something, it will either get it from there, or failing that, from add-on packages.

That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required.

Due to inter-package dependencies, that plan can easily be foiled.

In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages. The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.

[zbentley]

I agree about batteries-included languages, but that applies more to library-type tools, IMO, than language features. A library-type tool is something like "I need to get an md5 hash; I hope a function to do that is included with the language distribution so I don't need to go find a library!". A language feature is something in response to questions like "How do I express that I'm calling a method on an object? Or that I want to read a key out of a dictionary object? Or automatically generate code for a method when I call something that doesn't exist?". Those are sometimes implemented in terms of libraries, but are instead often implemented in the syntax and behavior of the language/runtime itself. For example, Java has a specific syntax for "call a method on an object instance or class", and that's "thing.methodname()". Sure, it could be implemented in the library style ("call_method(thing, 'methodname', args[])"), but that's typically not what people want. Perl tends to have, in my experience, an outlier surplus of language features and libraries.

I'm only arguing for moderation in the syntactic/language-feature department; I agree with you that a good, curated set of wide-ranging libraries is something that every language should have--ideally as part of the core distribution.

[kazinator]

> but that applies more to library-type tools, IMO, than language features.

I'm a Lisp person of many years, so my perception of this distinction has gradually atrophied, dried and fallen off. But even in this context, I would still rather have a larger language (more stuff which is Just There), even though more kinds of things can be add-on modules in Lisp than in something like Perl.