|
|
|
|
|
|
by zbentley
3132 days ago
|
|
|
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. |
|
|
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.