I take a very cynical view of these things, and from that perspective it doesn't surprise me at all, really. My cynical view is that the "lousy" ones are popular because they are easy even for non-technical people to learn well enough to be useful in the majority of business settings.
This sets up a kind of feedback loop: there is an abundant supply of "cheap" labor who can use these languages, which companies love, and so they create more jobs for this labor market to fill, which means more people want to fill it (since there are jobs there).
Edit: 1) I would disagree that python is a "lousy" language; 2) To give some perspective regarding where I come from, the vast majority of my experience is with statically typed languages like C, C++ and Java; I prefer them and in my experience they are at least as easy to develop with as any of the dynamic languages that are popular.
The commoditization of web devs will occur, it's just a matter of when. Consider it the collateral damage from ever-more-powerful frameworks, a de-emphasis on SOLID-type software architecture, and businesses wanting to pay less for developers.
Couldn't agree more. I'd argue it's already well on its way. It seems there has been a resurgence in companies trying to shoehorn every application into a specific development pipeline within the last several years (specifically, the HTML5/JavaScript in-the-browser solution, rather than a more appropriate native solution). It happens every so often in this industry, but lately it seems to have accelerated.
I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables.
Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).
I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables.
There is very little in terms of "provability" that either C++ or its types give you. Proving anything really interesting (for example, the absence of race conditions in concurrent code) still seems like pretty much an arduous process in languages not explicitly designed for such things.
Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).
That didn't seem very comprehensible to me, but if you're claiming that in Ruby, you can modify member variables of someone's objects, well, you can't, unless you use reflection as well (not only that, but the access to member variables is object-based, rather than class-based, so you can't access the member variables of an object from any other object, even if they are of the same class, unlike in C++ - so much for the "objects communicate by passing messages" in C++!). More to the point, in C++, you can always cast a pointer into something that makes the raw data accessible. There's enough stuff in C++ for you to blow your whole leg off instead of just shooting yourself into the foot.
Take for example, proper use of a unique_ptr<lock_guard<std::mutex> > in C++. You can pass around the unique_ptr, and guarantee that you are in "unique ownership" of a particular lock at compile-time.
In C++, you may not be able to prove "the lack of race conditions", but you can prove things like "I'm the only one who is holding onto this mutex right now" thanks to stuff like unique_ptr... which tracks that stuff. These primitive proofs are performed at compiletime, and have little-to-no effect on runtime as well.
Stronger languages with stronger type-systems (ie: Haskell) can prove / disprove which code has side-effects... because you've explicitly passed the Monad around. (Note: Code without side-effects is guaranteed to not have race conditions).
So yes, there are important things you can prove using the type-system. More importantly, it is the compiler's job to automatically conduct these proofs every compile cycle.
Alternate theory: "lousy" is a subjective measure, and those languages are popular because in many other peoples' subjective reality, they are not lousy. Just a theory though, by all means, keep thinking that languages are objectively ranked identically to your subjective ranking and anybody using ones at the bottom are just dumb dumbs who are incapable of using the ones at the top.
I didn't rank any languages. I made an observation that it is easier for non-technical people to pick up dynamically typed languages and be productive enough for use in many business cases than to pick up statically typed ones. That doesn't mean the dynamically typed ones are "easier" or "worse" than statically typed ones. It doesn't mean people who prefer them or learn programming with them are "dumb dumbs," either. There's a reason I put "lousy" in quotes and didn't flat out agree that they were, in fact, "lousy".
Seems to me that's a chip on your shoulder; not mine.
Hmmm, I re-read your comment and its parent a couple times, and maybe I didn't give proper credence to your sarcasm quotes. I do think that your comment strongly implies agreement with the non-sarcasm-quote-using parent comment, but hey, maybe that's really just my reading of it. Your edit also confusingly says that you don't think the "lousy" languages are really any easier than the static languages you prefer, despite your second paragraph seeming to say the opposite. So maybe I'll just bow out of trying to interpret what you think :)
I'll freely admit that it peeves me to no end when people make value judgments based on what programming languages people do and don't like and use, on both sides of the static/dynamic divide, so maybe I do have that chip on my shoulder.
This sets up a kind of feedback loop: there is an abundant supply of "cheap" labor who can use these languages, which companies love, and so they create more jobs for this labor market to fill, which means more people want to fill it (since there are jobs there).
Edit: 1) I would disagree that python is a "lousy" language; 2) To give some perspective regarding where I come from, the vast majority of my experience is with statically typed languages like C, C++ and Java; I prefer them and in my experience they are at least as easy to develop with as any of the dynamic languages that are popular.