They don't understand why "expressive, readable, writable" code is a good thing? I doubt that very much. I think their definition of those terms just differs from yours.
"their definition of those terms just differs from yours."
That is what most people don't understand.
There is a best language. It just varies from programmer to programmer. Also picking the "right" language for the job is overrated. Should pick the "right" language for the developer(or switched around pick devs who's right language is the one your code base is written in.)
No sarcasm intended: would C++ be a good choice for web development if it feels right for the developer?
In my short experience with several popular languages, there are certain niches for development. E.g. high-level web development (Python, Ruby, Perl), complex enterprise development (C#, Java), video games and embedded (C), general desktop software (C#, C++).
Within the niche, it is perfectly fine to chose any language within niche. However, to use langauges across niches is quite troublesome. No one cares if you use Ruby instead Python to write a web-site but people would raise eyebrows if you use C (counter-example: eBay).
Complex enterprise development: I doubt there is such a beast written in only one language. And I argue that Java is used because it is close to best for hordes of programmer drones working for enterprises. The non-hordes are why jruby, jython, scala are becoming popular.
pg did the airline ticket thing in Lisp cause it was best for him.
You claim short experience and reiterate long held stereotypes. I claim 20 years of experience and see a vastly different picture than you do.
Certain languages are clearly better suited to some niches, though. I just learned awk, and, in retrospect, it's obvious that I've reimplemented a subset of it in every other language I've used* . Sure, it's designed specifically for processing semi-structured textual data, but that's a surprisingly common situation. (Unix, man!) Since it's clearly a niche tool, it can dispense with a lot of boilerplate, and everything I need to know to use it fits in about 30 pages. (I've already written a couple useful three-line programs in it.) Likewise, if I have to calculate dependencies in a DAG, make immediately comes to mind.
I think the real problem is languages that don't have clear mechanisms in place for co-operating with other languages (and their libraries). Without an FFI or other integration, you're stuck with a languages' weak points. It's too easy to get bogged down rewriting everything in Lisp (or whatever).
* Granted, I don't like Perl (the heart of which is a sort of sprawling mega-awk).
Honestly, Python claims to sacrifice expressiveness and writibility for readability. That whole "there's only one way to do things" is the opposite of expressiveness.
If you want to optimize for writibility and expressiveness, you want a language that won't prevent you from doing anything you want to do. Lisp is definitely one of these languages.
Anyway, your comment reads of blatant fanboi-ing. If you like Python, that's great, just say that instead. It's much better than inventing bullshit "reasons".
Not taking sides here, just bringing up a potential counterpoint. I like Python, Lisp and a fair few other languages as well.
From my understanding, the "there's only one way to do things" idea generally applies at the smaller scales, so an argument could be made that it helps with expressiveness at larger scales, since once you know the idioms you don't need to choose between them - ie you can just type it in and keep going and save the mindspace that making a choice between the multiple equivalent options would have required.
Of course, that only makes sense if the "one way to do things" is eliminating choices that are 100% functionally identical, and you can also get bitten if you need something just outside of what the idiom can do nicely, but I thought it was a point worth bringing up.
Expressiveness isn't about saving time discriminating among different options. That's more like a form of simplicity. Expressiveness is a soft quality and is about being able to convey the thought or feeling of an algorithm in a natural way to a human. This helps when you're reading code and when you're conjuring up the code in your head.
Functionally identical patterns of code are not equivalently expressive. Certainly the computer doesn't care, but code is written for humans first and foremost. The more ways I can express a functionally equivalent operation, the more expressive the language is. This is because (ideally) each of the different ways has a unique feeling to it that evokes the right intuition needed in the right contexts.
It appears that we were using different meanings for expressiveness though - yours was focusing on communicating both the feel and the function of the code, mine was focusing on communicating efficiently[1].
I don't think that they're orthogonal, and I'm not sure at the level that "there's only one way to do anything" is normally applied in Python that it negatively effects either, especially since the implied full version seems to be "there's only one way to do anything if you don't have a reason to do differently".
Not that it helps with communicating the feel of an algorithm, but at least it doesn't necessarily hurt. I was only trying to point out that "there's only one way to do things" may not actually be the opposite of expressiveness. Liberally
applied it's possibly neutral or better.
[1] An argument could be made that accurately communicating the feel of the code is the most efficient way to communicate it, although I'm more concerned with the time it takes both to read and to write the code - surely at some point of massaging your code for readability you reach the point diminishing returns :)
Something hardcore lispers don't fully understand.