Stop hating Java(andrzejonsoftware.blogspot.com) |
Stop hating Java(andrzejonsoftware.blogspot.com) |
Because of cross-platformity, or is there more?
[considering that there are 17000 Indonesian islands, this statement might not be factual]
I do agree that Java has some junk in it, but you don't have to use it. I'm sure I could say the same thing about any language though. I still prefer Java though.
This piece seems to be mistaking criticism of technology with criticism of people, which is what happens when nerds get too personally attached to languages, frameworks, OSs, etc. I don't think Java folks are stupid for using XML, or anything of the sort. The above succinctly lays out the reasons why that choice made sense at the time, but times change, and that is not a reflection on the judgment of those who made this decision.
The more advocacy happens for a technology - often - the more adoption it gets. While not entirely a zero-sum game, a tech choice for a company generally precludes them from seriously using alternatives. If a company switches from Java to Ruby, for example, that's fewer Java jobs, and more Ruby jobs. I'm working with an org doing this right now, and they will then be looking for Ruby devs instead of Java devs. Seems pretty straightforward to me.
Why would the OP using languages other than Java stop people hating Java?
"Available for Rails contracts/consulting"
Looking at more recent work such as the lovely Play framework and the influence of new JVM languages such as Clojure and Scala, it looks like things are improving in Java-land. It's still a bit dated and clunky compared to Ruby and Python (let alone Clojure/Scala or even Groovy) but it's not as bad as people make out.
The moment you set up "throw it over the wall" processes where architects are rewarded for architecture and implementors are blamed for bugs, you are going down the road to something that looks like J2EE no matter where you start.
Thank you for writing this. When I first read the GoF Design Pattern Book I thought "this is the reason, why the code in my project is bloated, unmaintainable and shitty".
Not sure if you know the history, but the authors of the book really only collected the patterns that they had seen around them in Smalltalk and C++ code. They wrote a catalog so we could all refer to the same name instead of using different names for the same concept. They identified the common problems that these patterns tried to solve and they also identified the trade-offs. Oh yes, they identified trade-offs!
Unfortunately, many developers thought that they had to put as many patterns as possible in their code, which was not the intent of the GoF. Ralph Johnson said that they received emails like "I have now used 15 patterns in my project, do you think we should use more?"
Andrzej mentions in his blog post that Java (and C++) lacks dynamic capabilities so this is why sometimes, you need these design patterns to make your code more easily extendable. Other patterns are good even with dynamic languages (observers...).
"You've got a singleton class with a single method and no members . . . why don't you make this thing a function?"
"Uh, it wouldn't be a pattern then, would it. Um, would it?"
And the XML. Oh, dear Lord. I have a doctor's slip now stating that I am allergic to XML and that's the reason I'm breaking out in hives, whooping for air and leaving the room.
I sometimes wonder what would have happened to the software industry if the entries in GoF had been written in a different order. Would we see a plague of Visitors and Observers?
[edit] I didn't mean to sound so negative about GoF. Know the patterns so you know when to use them, and when to avoid them. You can't debate these decisions when you're ignorant of design principals and history.
I agree that it's not java the language (java's boring, but not unusable), it's the java culture from the last decade that drives people away.
This lack of abstraction mechanisms was by design; it was supposed to be simpler than C++, and it is. Unfortunately, it came from an era where people still thought OO was the uberparadigm and it met every need in it simplest form. I think I can safely close the book on that as being false; at the very least you need OO with borrowed features from older-generation functional languages like closures and first-class functions, like Python or Ruby.
Have you tried Java EE6 (the app-servers that support Java EE6 or just the subset of Java EE6 have improved significantly as well via OSGi).
I'm worried that people will think I'm a broken record on the topic of java, but this discussion is coming up a lot these days, and I think a lot of people are doing a mental re-evaluation of Java. One thing that comes up a lot is that Java itself isn't terrible, but J2EE (as well as Spring and other frameworks many developers consider over-complicated) has made the experience of being a java developer (especially someone new to the environment) unpleasant.
While some people mention frameworks like Play, I'm interested in what people think of going back to the Servlet + Libraries approach that was common in 2004, just before Struts/Spring hit the scene. It's verbose, and I'm not saying we should just go back to the way things were, but I think developers might want to embrace the low levelness and verboseness of Java.
My take on it is - if I'm happy to work within the conventions of a framework, then I'd probably be happy with Rails or Django. If I want to write Java, then I probably want a very detailed level of control over my code base. In this case, it might make sense to start with the bare-bones (servlets and jdbc), and grow into what I think I need through libraries rather than an over-arching framework like Spring.
In general, I think I would want to use MVC and DI, but I'd like these things to be as unobtrusive as possible, and easy to add or remove, like libraries rather than something that dominates my code from the very beginning...
Honestly, my thoughts aren't completely formed on this yet... I just find it interesting how so many people on HN are starting to discuss this now. Often, there's a reason that developers start to focus on a particular issue at the same time.
If I had to name the single biggest class of make-work in my life in the last 10 years, that would be it: maintaining legacy Struts crap.
The creator of struts should be in Gitmo for a year or two, perhaps with access to a functional programming environment a few hours a week if he behaves himself :-)
Java: providing a job with benefits. Like the episode of "The Simpsons" where Homer has to go back to the nuclear power plant to work, to pay for his daughter -- "Do it for her."
So just because Rails developers hate something doesn't mean it's generally evil. It might just be wrong for Rails. Many things are; otherwise Rails would have no texture. Saying no to things is what design is about.
Now let's talk about hate. Everyone hates something. There is nothing wrong with hating things. Hate is just personal taste turned up to eleven. You should strive to hate politely and with grace, to realize that other people love the things you hate and are nonetheless human, and probably even smart. And you should strive to remember that there's an important difference between the things you hate and things that objectively suck. Java, for example, does not suck. Not always. Lots of work has gone into it. Lots of Java-based tools are essential. There are big classes of problem for which Java is currently the best solution.
Nonetheless, I hate Java. It is a handy mental shortcut, one that has yet to lead me astray. My belief is that the problems for which Java-the-language is the solution are problems I don't want to work on, and that I don't have enough time in my life to address the problems I do want to work on, so I should simply develop a Java allergy that kicks in whenever I see the generics syntax and that causes my eyes to water until I flee towards fresh air. It works well.
(What's sad is when you find yourself hating something that is smack-dab in the middle of a set of problems that you want to work on. Hello, PHP! This requires a much richer set of coping techniques than simple allergic avoidance.)
(And, of course, Java is not just a language, and JRuby appears, from the outside, to be awesome, and my curiosity about Clojure is rising, so I may soon temper my simple hatred of Java into a rich melange of love and hate. The stuff of which novels are born, really.)
"Refactoring came to us from Java"
Nothing of refactoring came from Java or its community. The formalization of its concepts largely came from the Smalltalk community (Opdyke, Johnson '90; Opdyke '92; Johnson, Opdyke '93; Opdyke, Johnson '93), using unit tests to ensure refactorings don't change behavior came from the Smalltalk community and automated refactoring tools came from the Smalltalk community (Roberts, Brant, Johnson '97; Refactoring Browser http://st-www.cs.illinois.edu/users/brant/Refactory/)
In fact, as you may note both the concept and the name are older than Java itself.
The only claim to fame Java has in relation to refactoring is Smalltalk refugees reimplementing IDEs and refactoring browsers for it.
Stroustrup was dead on: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." The more popular a language is, the more people will complain about it. (And the more people will build crappy software around it.)
Definitely not. Especially not in this day and age. Java has a pretty good language, java has a good ecosystem, java has a passable standard library, but in 2011 java is a crummy language.
Edit: I'll also add that this is not limited to the Ruby community.
One last edit: General Patton once said, "Find what a man is cynical about, and you will know his weaknesses." or something like that. I think that quote applies here.
Other than that I develop much faster in Python or Javascript. I've come to love treating functions as first class objects, and I just don't love static typing that much anymore.
Getting my projects done more quickly has become more important than anything else. It just so happens that other languages than Java are better for that.
Java EE is an atrocity and it is just an over-enginnered pile of garbage.
Try play framework. I just finished a webapp in play and the whole experience has been awesome. IntelliJ + Play + MongoDB is AWESOME.
I haven't messed with the Scala version, but I can imagine that Scala + Play is even more interesting. Either way, Java EE/EJB/XMLHell is probably my most people hate Java. Also, Swing was garbage too, but who builds desktop apps in Java anymore anyway?
Keep in mind that the latest EE6 spec and most modern Java frameworks make XML optional (supported only for backward compatibility or just because it's there).
But writing it? Very nice, aside from the somewhat iffy SQL layer. (I'm not a huge ORM fan, and the process of actually writing SQL through Anorm can be problematic.)
This most likely comes from seeing Java (or x,y,z) as thee only tool one would possibly need. Unfortunately, Java much like every other lang should be seen as a tool with pros and cons, in a chest of other tools.
Also, it's bad measure to only consider deployment size regarding any platform effectiveness.
" Let's learn more from Java". I'd rather learn more from "Computer Science" and apply those techniques to Java. Not the other way around.
Just reading this and thinking: "oh man, if ONLY that was my problem".
Java's ecosystem is changing, albeit slowly.
I hate how much work Java makes me do to get things done.
It doesn't matter if you're writing "hello world", an English to pig-latin converter, a web server or a lisp interpreter. In every case, it's a lot less code and a lot less work to do in Ruby than it is in Java. Java is just too low-level of a language for anything I'm working on, and in those cases where I do need to get closer to the metal, it's easy enough just to use C.
Ruby is fun and really nice for exploring ideas though. It doesn't marry you to an IDE and you can go from idea to reality quite fast with a text editor and a command line. Unfortunately, Rails is a lot of meta-programming magic and syntactic sugar that can really obscure the language for newbies. It's changed the landscape for web frameworks and I would even say mobile as well. RoR didn't invent MVC but it certainly refined our thinking of frameworks in general.
But some languages make writing elegant code easier than others (compare C to Python, for example).
I can write some terse AND elegant list comprehension code in Python that takes lines and lines of crappy looping in Java, but I can also write some seriously terse code to centralize business logic via a web service with automatic transaction and security management and have it perform an order of magnitude faster than a similar implementation in Ruby or Python (JEE 6). To me, that is elegant.
Likewise, I can do some elegantly maintainable things with .NET generics that I can't do with Java's lame erasure based implementation.
Of course, you could always just takes Einstein's opinion :) "If you are out to describe the truth, leave elegance to the tailor."
Skills go where the jobs are: http://www.indeed.com/jobs?q=ruby&l=Omaha%2C+NE = 11 jobs http://www.indeed.com/jobs?q=j2ee&l=Omaha%2C+NE = 101 jobs
Bottom line: if you expect to hire developers, in most places, you'll want a language with the deepest bench of talent. The trick is to resist the Java framework nazi's and keep it simple.
My own experience with Rail is that I quickly wanted to see inside and control all of the implicit stuff that was going on, and I needed to invest a lot more time to learn Ruby to have the knowledge that would give the amount of control I wanted.
I'm far from a guru, but I've been able to pick up quite a few different languages, frameworks and structures over my tenure. It's the ones that limit themselves to a single language (be it Java or not) for long periods of time that you need to worry about.
These are the programmers that will build a square wheel because that's what the spec told them to build. Employ them at your peril.
Having recently decided to abandon my anti-Java prejudice from way back I've discovered that everything I hated about Java back in the 90s is still there, only worse.
COBOL at least had the excuse that it was first.
Even within the Ruby jobs, the majority have a Java requirement within them as well.
Been hearing Ruby aficionados for like a decade, but sorry, it just hasn't penetrated.
Before you begin to troll me, what I'm saying is that >>the metric is not valid<<, not that one language is better than the other.
The jobs metric tells me that if you hope to hire >>experienced<< Ruby programmers, you can probably expect to have fewer to choose from, possibly wait longer, fight harder, and pay more to get them.
I'm not saying you can't hire good programmers and give them a few months to transition, but that wouldn't work for my bootstrapped startup that's planning to ship product in 90 days.
You might say, yeah, but with 2k Java jobs, you have to compete against a lot of employers. Personally, I'd rather take my chances with a deeper pool of Java talent that I can out recruit the competition.
The best thing for people would be to move on, not in anger but to explore as many languages as possible. Java could very well be the best thing for some BUT you can't really say until you go out and look. From where I'm standing (subjective since I left Java ages ago) most people that go out to explore new things rarely go back.
When Java came out it was a big step forward for a lot of people. Most of the scripting languages with OO features (Ruby, Python, PHP) have a lot of Java influence.
I see the problem is that Java stopped evolving a decade ago. C# shows the kind of path that a Java-like language can follow to get better, and Java just hasn't been moving.
Other than that I'm pretty much in agreement. Even not so long ago as 2002 people would say "Let's use Java" when they really were saying "Let's NOT use C++." C# is a great language, though MS didn't put their heart into really killing Java. I think Microsoft could have dominated with C# outside of Windows World (lots of enterprises still rely on Linux, and Java's not a bad choice for an enterprise app on a Linux server, then there's Android..) if they put more backing behind Mono or just open sourced everything to begin with.
I find it ridiculously verbose, and the lack of closures (or even passing around code references) leads to the perceived overengineering mentioned in the post (I'm not sure it's really overengineering all the time - it's just that a rather rigid language forces you to write huge amounts of code to make your library flexible).
That said I have no problem with using programs written in Java - in that case somebody else has already dealt with the things I don't like about Java.
GWT does have its drawbacks, but we do a lot of complex work in it with very minimal native javascript and support a site with hundreds of thousands of active users.
And if you use them everywhere, then welcome to Rails, where to service more than 1 request at a time you actually have to run multiple instances of the whole app behind a balancer.
Comparing Java to Ruby is a philosophical matter, comparing Java to C# illustrates numerous ways in which the language and runtime (real support for generics) could improve while staying true to its market.
The article honestly looks like a comparison between rails and java rather than ruby and java.
The article states:
... Whenever you needed a pluggable system in your code you had to abstract away some concepts in order to make it work. Ruby lets us do it much easier and that’s cool. ...
Can someone give a concrete example of this?
That said, it is possible to write thin apps with Java today, much by the innovations brought by SpringSource. Roo is a rails-like framework to Java that works really well, and the Spring container took out the word EJB from almost every new project.
If I have to choose a language to start a new project today I will probably go with other language, but I have no problems working with Java at all.
Kinda like that one girlfriend that messed you up so bad that once you got over everything and realized life was ok, you never felt like rolling by her house ever again. :)
Also, Scala and Clojure are wonderful languages so I don't understand some of the negative comments about them.
The tough part about languages like Scala and Clojure is that the existing Java ecosystem bleeds through heavily. For instance, while Scala boils away a lot of repetitious code, it's still there under the hood. It feels like an architectural band-aid. That may change as the ecosystem around each language evolves and writes frameworks and libraries in Scala/Clojure rather than reusing them from Java. However in Scala's case it's as if the language is being marketed as the next evolution of Java-as-a-language with a heavy emphasis on reusing existing Java frameworks and libraries, so I expect the people writing code in the existing Java community to migrate to Scala.
Elitest? Maybe. But I think it's a realistic view.
The newer JVM languages are great if you already have an existing Java codebase, however I'm struggling to find sound reasons to use Scala on a geen field project.
I don't understand this argument. Even so-called elegant languages like Scheme still have 'repetitious' MOV, JNE, etc instructions under the hood. Unless you're running on a lisp machine, everything you write executes very repetitiously in machine language under the hood.
Why make a distinction between one abstraction and another? All of them are architectural band-aids, to use your parlance.
This idea of developing an "allergy" / "hate" for Java reminded me of http://www.npr.org/blogs/monkeysee/2011/04/21/135508305/the-... ( HN discussion at http://news.ycombinator.com/item?id=2464764 ). More specifically the part about "culling":
Culling is the choosing you do for yourself. It's the sorting of what's worth your time and what's not worth your time. It's saying, "I deem Keeping Up With The Kardashians a poor use of my time, and therefore, I choose not to watch it." It's saying, "I read the last Jonathan Franzen book and fell asleep six times, so I'm not going to read this one."
[...]
What I've observed in recent years is that many people, in cultural conversations, are far more interested in culling than in surrender. And they want to cull as aggressively as they can. After all, you can eliminate a lot of discernment you'd otherwise have to apply to your choices of books if you say, "All genre fiction is trash." [...]
The same goes for throwing out foreign films, documentaries, classical music, fantasy novels, soap operas, humor, or westerns. I see people culling by category, broadly and aggressively: television is not important, popular fiction is not important, blockbuster movies are not important.
--------------------------------------------
I also have this avoidance mechanism. I don't have enough time to learn about each programming language / framework / paradigm, so I kind of hate / ignore some of these, without really knowing them (PHP, .NET, Windows, "enterprisey Java solutions"...). Not sure if it's the right thing to do, but I still have plenty to learn with the languages / frameworks I am interested in...
I'm not even certain why this has happened. As best I can figure, I am trying to create something and am still stuck in the phase where I figure out what the hell it is.
We need more devs who are not so emotionally invested in their tools. Not that they shouldn't care about them, but the loud-mouthed, posturing alpha dev stereotype gets too much airtime on the Internet because they instigate drama and drive hits by playing on the audience. It is little more than bikeshedding, ultimately.
They often make remarks about how Rails is easy and Java programming is where real men make their mark.
I think this comes down to a need for people to feel proud about the tools they use and the things they make.
I've had an Enterprise Java guy telling me once that "programming and Object Orientation got lost with those simpler, easy-to-use language and frameworks", referring to Ruby and Rails.
I dunno about that. Alan Kay would probably say that it got lost with C++ and Java, but YMMV.
Also, one word: speed.
But... I don't really think it boils down to this, it's not like one is better than the other. Proof is that both communities are learning from each other, and there's also JRuby... it's a great thing.
After some good natured ribbing that he 'doesn't hate Java developers, he just feels bad for them' He finally told me quite directly that he was apprehensive to move forward with me because hes worked with Java devs who made the jump to Python and they wrote Python code that looked like Java and he wasn't certain I'd be any different.
It was quite bizarre as he had access to a lot of my Python code.
If you asked me today what language would I use for a new web project, I don't think I'd pick a C based language. I don't really have much against that class - I use Objective-C every day. But I think it really comes down to the frameworks and libraries.
I spent the better part of the dot com coding in Java and C++. Towards the end of my Java days, the time it took to get ideas from paper to usable screen with JSPs, Spring, Hibernate - for one developer - seemed like forever. To make matters worse (and not so much Java's fault), I normalized the shit outta the database (a dba would have loved it) and having that fine grain of a data model just added insult to injury. So when I look at 'Java hate', I don't per say outright hate it, but I'm adverse to using it - especially for anything web. If you have a nice SOA, then I could see maybe using it for some services.
The last Java coding I did was in 2006 - that was my last Java contract client. After that, I switched to Ruby/Rails and that was that. A typical story I'm sure. Do I go to meetups and bash Java? No. Is the "eww, that would be like Java" heard around our office (current company is a Rails shop)? Yes.
However, my current company is hitting a ceiling with Rails. The fat model paradigm is starting to break down. Like us, as your project/app/company starts getting bigger and bigger, you start to hit growing pains with Rails. So I've been looking back at my Java history to find other patterns that were used to take some of the weight off the models and Modules where people have been putting things. Basically, Rails (IMO) is great to get you to a certain point, but after your system grows to a certain size, you have to start thinking about other ways to architect it. I think this is where SOA comes in and the data exchange is all done via json.
Would we consider using Java for any service? Probably not. Why? Because of the time and resources required to actually deploy the services. Like TFA says, Java picked XML. If someone actually made a simple app server where apps could be setup and deployed via properties (remember those?), then that might take some of the Java deployment sting out. Or, maybe if our team grabbed a dedicated release engineer, that might help.
So in the end, I don't think of myself or anyone I work with insecure about learning a new language. Most of the devs I work with came from a Java background. What makes more sense is being able to iterate very quickly over your ideas and just get shit done. This is why Ruby/Rails has been so successful. I don't find being cynical about Java a weakness at all. What would be worse in my mind is to get someone in who is not productive with the tools they're using. And for me writing web apps, I just don't feel productive using Java and its associated frameworks/libs/tools/servers.
That's not to say they still don't have their niche for high performance applications. It's just that in most cases other, more expressive languages are usually a better choice.
C++ is another matter entirely. My experience is pre-Boost, so I don't consider myself qualified to debate current approaches.
I'm not guaranteeing that this is true in an objective sense, but then again I can't guarantee that anything is true in an objective sense (I'm no philosopher). However, take a lot of people with a similar opinion and the voices tend to add up.
Abraham Lincoln once said "If you are going to quote a man on the Internet make it accurate", or words to that effect.
Only messing, googled and it seems to be "Watch what people are cynical about, and one can often discover what they lack."
Intellectual honesty is always in short supply on the Internet, it'd seem.
Care to explain this one? All the code I have written for the past 10 years do not need to be recompiled and can run on Windows/Linux/Mac/*BSD 32 bit/64 bit. And I used IO, NIO, sockets, threads, files (not necessarily high-level stuff).
But the ultimate lesson was that the intersection of all operating systems is an awful place to live. Because Java's not-exactly-native widgets often have the wrong look, it feels generic. Because they often have subtly different semantics, it feels slightly alien. Because platform-specific behaviors like drag and drop generally don't work right, it feels like an outsider, even though it's running on your machine. And because the app requires a giant brick of a runtime that generally hasn't been preloaded by anything else, it starts so slowly that you can practically hear the gnomes turning the rusty crank on the starter motor.
And it's not as if these are fatal objections. Clearly, based on the success of the web, they are not. But the lesson has been: If you're going to run an idiosyncratically-designed slow-loading quirky app that's imprisoned in it's own window why not just run a web app. And that's what people do.
But I think everyone has known for a long time now; that's not Java's sweet spot. It's do-able, but for obvious reasons it's harder to do cross-platform, and they made a few large missteps along the way trying to crack that particular nut.
Nowadays the vast majority of my Java work is server-side, and it all runs anywhere, without a hitch. The last time I had cross-platform Java issues with server-side code was on an AS/400.
Which is why Play is freaking awesome--well, one of the reasons.
I've really only been viewing this from the deployment side for quite a while, but when I'm trying to help you troubleshoot your relatively simple webapp, and I have thousands of lines of stacktraces that bubbled up through a half dozen frameworks, it's hard to blame just the language.
I seem to have replaced these hobbies with reading HN, reading books (lots of non-fiction), and toying with technical stuff (programming languages, libraries, security, ergonomy...).
While I learn a lot with these "productive" hobbies, I sometimes think I might be missing out on my previous hobbies... The NPR article made me realize I might have "culled" too much.
But JUnit did make them mainstream, and so did Eclipse' refactorings.
I've deployed onto primarily Solaris and various flavors of Linux with no problems, but don't have much experience with *BSD... though I've generally assumed it would be a similar experience.
You did tell him Ruby is roughly as old as Java, Python is older and Smalltalk predates Java by almost 15 years right?
It depends on the programming language one uses, really. You won't find many references to these patterns on Python's mailing list (or at least I didn't when I was new to the language and used to spend a lot of time there, ~6-7 years ago). Also, when I've tried to learn Lisp or Erlang I didn't find any mentions to such particular patterns (or maybe only in passing), the focus was on something else. And I'm sure there are a lot of other languages outhere who don't bother with patterns.
Adapter is a generic name. Compatibility modules that enable python code to run with python 2 and python 3 are adapters. For example: https://github.com/bartdag/py4j/blob/master/py4j-python/src/...
As for the visitor pattern: http://docs.python.org/library/compiler.html#module-compiler...
They're just not called design patterns. But note that the things in GOF weren't called design patterns in C++ until 1995 either (the GOF book largely predates real use of Java). They were called techniques, or just things you might see in multiple projects.
I am pretty convinced that GoF did not expect how popular their book may become. Looking back, it is always easier to judge.
Looking back, with no offense to GoF, what happened can be understood. GoF did a great work for all these "I badly need to sell something new and hot to all these saturated development shops" guys. Read the pattern book once, teach it a hundred times for 2000$ a person. Great stuff.
Now, of course it is due to the single developer to use patterns or not. But the average developer is - well average. Using a pattern is much easier than to understand, when to use and when not to use.
I indeed should have been more precise in my statement: our code got bloated and unmaintainable because there are pattern all over. This is not GoFs fault, it is the fault of all the developers who just read the book and want to apply everything instantly, everywhere. It is also the fault of the community, who did not recognize at once, that pattern should be used only, if they solve a problem that is hard to solve without patterns.
Tools matter, at every scale.
I can bootstrap a project in Ruby or Python considerably faster than I can in Java. But when it comes time to scale, Java usually -- not always, but most of the time -- wins out. They all can do it. None is really more expressive than any other. It's just the level of effort involved. And the pros and cons of each usually start to even out as a project grows.
For problems with low domain complexity but involve a lot of boiler plate code, a more expressive language wins out. Likewise, if you spend the majority of your time thinking about the problem and little time on the actual implementation, then the language may not be your bottleneck.
They're not 'Do this, and you'll have good code', they're just an observation that good code may often use many of these patterns - not because they're forced in there, but because the solution simply maps well to that kind of model.
It's been a while since I read it, but I remember using the book itself as ammo for arguing when not to use particular patterns. They cover trade-offs, and the situations when the pattern may be appropriate or not.