The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather drastically with the "principle of least astonishment". This is not to say that making everything out of eg Java boilerplate is the solution. The key is writing well-behaved and consistent code, which you can do in most languages.
This argument is common, but I think it's bogus. There's plenty of astonishing Java out there.
More rigid languages don't lead to less astonishment under complexity. A given line of code may contain less astonishment, because there are fewer possibilities for what it might be doing, but what matters is global understanding, not local. The meaning of a program is not the sum of the meaning of its parts. Otherwise we'd all be writing in assembler; it's easy to say what this is doing, locally:
mov eax, [ebp + 8]
The key is writing well-behaved and consistent code, which you can do in most languages.
But the set of problems for which a well-behaved and consistent program is readily writeable is not the same for all languages.
The argument I take is that while you can write well-behaved and consistent code in any language, there is no language that forces you to do so. So picking a language on the basis that it will force/encourage people to write well-behaved and consistent code--even if they don't want to/don't know how to/don't give a toss because they're a cheap contractor six time zones away--is a broken choice.
Programming languages are UIs. Your assertion is tantamount to saying that there is no such thing as a bad UI; that a choice between UIs is a broken choice, because you can still get your job done no matter what UI is there, or similarly you can still do a crappy job no matter what UI you use.
But this is just wrong-headed thinking, to my mind. UI definitely influences user behaviour. One thing currently in vogue is game mechanics; the whole point of using game mechanics in your UI is to encourage certain kinds of behaviours, and it works, dagnabbit! Most UIs that have any coherence to them at all have a way of working with their grain, and many more ways of working against their grain. If they're good UIs, working with the grain ought to reduce your non-essential work load and make working a pleasure. If they're poor, you'll have to work against the grain, fighting the design, to get your job done.
Programming languages are directly analogous to this.
I agree with everything you're saying about programming languages having a grain, and of making some things easy and other things hard. That's the general case.
However, the two specifics we're talking about are well-behaved code and consistent code. Most language in theory make it ridiculously easy to re-use code, to make code DRY. Languages like Ruby actually give you more tools for making code consistent than languages like Java.
Yet, there is a lot of awful Ruby code and some elegant Java code. I've seen some amazing assembler code. It seems that somehow languages don't seem to have a lot of influence over what we might call architecture.
Perhaps the issue is that languages are hand tools, but programs are cathedrals.
p.s. If I had to bet, I'd say there is more of a correlation between languages and architecture than a causal relationship. Paul wrote about this some time ago: http://www.paulgraham.com/pypar.html
The problem with saying "you can do things in whatever
way you want in Ruby" is that the moment you have more
than one developer it collides rather drastically with
the "principle of least astonishment".
I've solved that problem by actually talking with the other developers and agreeing to some common practices.
Not every problem requires a technical solution. Social solutions often work just fine.
That works great for two people. Maybe even 20 people. But try to write a 1M+ line app by meeting at the water cooler.
One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everything else." His response, "Wait, how do you free memory?"
I had the opposite problem at a student intern gig. I hadn't experienced smart pointers before, and was double freeing memory accidentally. The fun part was that the unit tests for my code always worked. It was always someone else's code which appeared to break inconsistently after my change ;)
You live, you learn. We picked it up remarkably quickly in the end, basically because the company had their process working right: clean codebase, solid testing, and regular code reviews.
