That doesn't change the fact that I'm very glad most Smalltalks ship with ROE or GLORP, or that C# ships with LINQ. It just says that I want to be able to add features as easily as the language designer can.
If a language does not have closures nor more complex control flow features, you really can't implement PL features as equivalently easy-to-use libraries. IMHO, that's why most mainstream languages continue to add superficial features rather than fix the core problems in their PL.
(I wrote a whole book on how to best use Catalyst. A year later, it's nearly all wrong. This seems to upset people, as now they "are wrong". But it doesn't really matter; they can incrementally move in the direction of what we consider "not wrong" today, and, wrong or not, it's not like their app doesn't work. Personally, I am happy that everything becomes outdated so quickly, as it means that I can be more productive, and my apps can be easier to write and maintain. But people are weird...)
I think programmers will also trade actual flexibility for an IDE that appears to make their language flexible. Are there any really popular languages today where bloated IDEs aren't "required"? (I consider Java and C# to be the "really popular" languages today. I don't use them, but millions of other people do.)
The main problem with all of this is that programmers aren't really responsible for deciding which programming technology will be used. A programmer wants macros. A hiring manager wants the ability to throw a dart at a list of names and find a programmer that knows that language. Guess whose input wins? (Combine this with the fact that people think programming is a "cool" profession, and you end up with 90% of the practitioners not actually knowing how to program or what programming is. Does it surprise anyone that cool GUIs beat complex computer science topics?)
The good news is, you don't have to be part of the problem. There is hardly any reason to use the "popular" languages. They don't have better platform support, they don't have better libraries, and they don't have better tools. So don't worry about them, they are for other people :)
These things together mean that using a popular language in the way that most people use it is easy -- it's the path of least resistance in a lot of instances. Using languages that are cool, have neat features (or the ability to build them), and/or have higher abstractions is fun for play, but it turns out to feel like you're swimming upstream when you have to do the boring requirements-laden task that you've been handed.
There's more than one reason for that, but collectively they add up to why I use PHP for things I just want to get working quickly, or for job-like things, and lisps or other small-community languages when I'm doing something just for fun.
Economics has given us the wonderfully pretentious sounding term "positive network externalities" to describe products that become more valuable, the more people who use them. Simple concept, big, impressive term.
http://www.welton.it/articles/programming_language_economics
This is why I'm not interested in Clojure, regardless of how nice a lisp it may be. Java libraries are poorly-designed, the prospect of wrestling with them again brings back memories of frustration. And you can bet that no one will ever write better ones, because the community will discourage people from "duplicating functionality."
One of the best things about Clojure is how it makes Java libraries suck much less. For example, line-seq turns a Java BufferedReader into a lazy sequence of String's, one for each line in the file.
You still have the suckiness of the multiple lines it takes to instantiate and clean up the BufferedReader, but macros like with-open makes that suck a little bit less, too.
Stir in some macro-fu of your own, and now you have the benefits of Java libraries minus the boilerplate suckiness. Basically, it turns Java into a "your language features are my libraries" language, no mean feat.
There are many Clojure libraries that attempt to reimplement existing Java libraries. For instance, Ring is a HTTP specification for Clojure that reimplements much of the functionality of Java servlets.
It is easier to just steal Clojure's good features for CL. (funcallable everything is kind of nice.)
I'm working with matlab currently. It is simultaneously the best engineering tool ever and the worstest, lousiest development environment ever. It has tremendous shortcuts for doing things quickly and powerfully but everything has been added in haphazard, half-cocked, half-assed fashion.
I can see how the two face of matlab have evolved together in the way that Perl has amazing power and horrible maintainability. I don't see that they would have to have evolved together. Ruby, for example, does what Perl does but with more sanity.
I'll research lambdas.
But I meant it also in saying that Matlab is the greatest engineering tool ever. You can do amazing things in 200 lines. Then you do 400 lines and get caught in some BS for days. But if you remember to do only 200 lines (even just 2 lines), then you can be a very, very good and feel very productive.
Details and exact choices of libraries can be discussed, but... could you be more specific?
Or were you talking of 1990s code, before e.g. testing took over the Perl world? Nah, straw men like that on HN... not possible.
Again, Perl would have more justification if Ruby wasn't visible
I was hoping that any answer might be insightful.
(Readability is mostly a function of familiarity. Everything has advantages/disadvantages, if I'd list the problems with Perl, readability wouldn't be there.)
http://www.dagolden.com/index.php/199/time-for-second-editio...
I nominate Ruby as the first "your language features are my libraries" language to become legitimately popular. This is likely due to the fact that Rails provides the libraries that most web programmers want, in addition to the cool language features. But it also seems that the "Rails community" is enamored with how easy Ruby's flexible syntax makes it to extend the language in interesting ways. Thus, all of the fuss over adding methods to base classes, and whether or not, or when, it is a good idea to do so.
So I would say that Ruby has brought the idea of language features as libraries into the mainstream, as much as anything as geeky as programming languages can be considered mainstream.
(edit)
Without eventually making your own?
If you don't need additional libraries then you are probably doing things that the authors of the language/platform/framework thought would be necessary.
The other language language/platform/framework, which I am familiar with, is ColdFusion. If you are doing web development and fit with-in only the functionality available to you by default then you are fine. If you want to abstract away certain things or do more than average web development then outside libraries are necessary, especially in the user-interface side of things.
Of course it is hard to do programming without doing any metaprogramming at all, so new languages, like C#, have some basic metaprogramming features. But you have to market them as features of an otherwise fixed programming language or you'll scare people off. It's all about minimizing the number of things your customer has to think about. It's even worse if management is driving the choice/design of the language.