The Parley Letter(david.heinemeierhansson.com)
david.heinemeierhansson.com
The Parley Letter
http://david.heinemeierhansson.com/2012/the-parley-letter.html
6 comments
Not every new architectural idea is a good one. Lots fell by the wayside over the years. See J2EE or Naked Objects (I actually kinda liked that one). Bad ideas fail faster when criticism is brought forward which opens the floor to new, better ideas.
Constructive criticism, yes absolutely. Labelling things as wankery and reiterating that you don't see the point aren't. All they're showing is that you're missing the point.
Let me translate it for you, then. Wankery: Complexity brought on by the love of an abstract idea without meaningful practical benefit.
By definition I don't see the point in architectural exploits that can be labelled wankery.
By definition I don't see the point in architectural exploits that can be labelled wankery.
I know, you've repeated that several times. "Without meaningful practical benefit" is what I'm referring to when I say you keep stating that you're missing the point. Just because you happen to not see the meaningful practical benefit doesn't mean there isn't one.
That is one of the most common young nerd mistakes. "If I don't see the value in something, the people doing it must be idiots!" Rather than, say, "... I must not understand something here."
I made it a ton as a youth. I had to have about a thousand, "Oh, now I see what they're talking about" moments before I learned to keep my mouth shut long enough to actually learn something.
I made it a ton as a youth. I had to have about a thousand, "Oh, now I see what they're talking about" moments before I learned to keep my mouth shut long enough to actually learn something.
Agreed, but there has to be some filter. You can't just say, "I don't see the value in crystal healing, I must not understand something here." Sometimes, you do understand enough.
Well, it depends on how you do it. My original reaction was, "duh, idiocy." But once I paid more attention, I learned a lot about the emotional motivations behind it, the placebo effect, and why western medicine is so unsatisfying to people.
That's helpful, in that you can convince anybody by saying: "Although I have no evidence, I'm sure that crystal healing is bullshit and I'm waaaay smarter than you." All they read from that is contempt and arrogance; that approach to skepticism is basically bullying.
I think a better approach is the one taken by my doctor. When people come in with concerns about vaccines, she first listens to their fears about kids and patiently explains why those particular fears might sound reasonable, but in this case are unwarranted. It's not really about the facts; it's about the hand-holding. For her, the interaction isn't about being right, but about persuading people.
So I agree, but for very high values of "understand enough". It's not enough for me to know that they're wrong; I want to understand why they're wrong sufficiently to have empathy for their situation.
That's helpful, in that you can convince anybody by saying: "Although I have no evidence, I'm sure that crystal healing is bullshit and I'm waaaay smarter than you." All they read from that is contempt and arrogance; that approach to skepticism is basically bullying.
I think a better approach is the one taken by my doctor. When people come in with concerns about vaccines, she first listens to their fears about kids and patiently explains why those particular fears might sound reasonable, but in this case are unwarranted. It's not really about the facts; it's about the hand-holding. For her, the interaction isn't about being right, but about persuading people.
So I agree, but for very high values of "understand enough". It's not enough for me to know that they're wrong; I want to understand why they're wrong sufficiently to have empathy for their situation.
So how do you know DHH doesn't meet that threshold? (I don't think it's clear either way, but still "most common young nerd mistakes" is pretty dismissive.)
He might, but he certainly hasn't demonstrated otherwise. In particular, he's not saying, "I see where the REST crowd is going, but their crucial mistake is X." That, combined with DHH's well-earned reputation for arrogance, makes me think he's just doing his usual.
well the key word is "meaningful". and i think it can be stated in a more nuanced form:
wankery: architectural shenanigans which suffer significant diminishing returns on investment
wankery: architectural shenanigans which suffer significant diminishing returns on investment
If I were to buy into everything for which I see no practical benefit, 99% of what I buy into would be crap. By definition I can't tell the difference between snake oil and "stuff that is awesome, but I can't tell it's awesome." Therefore I reject everything for which I cannot see a practical benefit.
There are more states available to you than "buy in" and "reject utterly".
I should probably mention, before it's pointed out, that I mean REST is still in its infancy for web apps. It's more than proven itself as an excellent system architecture through the www.
Frank Lloyd Wright's designs are famous for having leaky roofs.
Or the hatred of other languages and frameworks? JEE (or J2EE as it is called in the article was truly both bloated and difficult to configure before adopting the "convention over configuration" ideal. But it's a very pleasant way to develop applications now.
> Now, I understand this particular guy is deeply invested in the MVC architecture. But that doesn't mean history stops here.
DHH himself has said that Rails MVC is not classical MVC. I don't know if Rails was the first framework to use this particular definition of MVC, but drawing a line between 1980's MVC and Rails is tenuous at best. Making a historical argument on this basis just doesn't hold up.
DHH himself has said that Rails MVC is not classical MVC. I don't know if Rails was the first framework to use this particular definition of MVC, but drawing a line between 1980's MVC and Rails is tenuous at best. Making a historical argument on this basis just doesn't hold up.
I agree wholeheartedly with with dhh's stated philosophy on the fact that code talks, bullshit walks and writing "future proof" code is a terrible idea (one that virtually every journeyman developer stupidly clings to for a while at some point in their career). But at the same time I'm not a Ruby fan, in large part due to the monkey patching ability he holds so dear.
Given the same philosophical outlook but perhaps less inherent trust in developers (including myself!) to always do the Right Thing, I've come to really appreciate Go as a no-bullshit language that does allow you to hang yourself (eg. the unsafe package, ability to ignore error returns via '_' variables, etc) but it at least makes you tie the rope to the ceiling before you can use it, so you have time to think about whether or not you really want to use it.
Given the same philosophical outlook but perhaps less inherent trust in developers (including myself!) to always do the Right Thing, I've come to really appreciate Go as a no-bullshit language that does allow you to hang yourself (eg. the unsafe package, ability to ignore error returns via '_' variables, etc) but it at least makes you tie the rope to the ceiling before you can use it, so you have time to think about whether or not you really want to use it.
He keeps writing "Parsley" instead of "Parely". For other non-native english speakers (like me), here's the defintion:
Parley:
Parley (/ˈpɑrli/) is a discussion or conference, especially one between enemies over terms of a truce or other matters. For example, in Julius Caesar (a tragedy by William Shakespeare), the respective followers and armies of Brutus and Antony are ready for a truce. The root of the word parley is parler, which is the French verb "to speak"
Parsely:
Garden parsley is a bright green, hairless, biennial, herbaceous plant in temperate climates, or an annual herb in subtropical and tropical areas.
Parley:
Parley (/ˈpɑrli/) is a discussion or conference, especially one between enemies over terms of a truce or other matters. For example, in Julius Caesar (a tragedy by William Shakespeare), the respective followers and armies of Brutus and Antony are ready for a truce. The root of the word parley is parler, which is the French verb "to speak"
Parsely:
Garden parsley is a bright green, hairless, biennial, herbaceous plant in temperate climates, or an annual herb in subtropical and tropical areas.
My guess is that iOS autocorrect strikes again. :)
Autocorrect is a bad idea. The kind of spelling error that iOS corrects (At least as far as I know.) is a syntactic error. Whereas the kind of error that autocorrect introduces is a semantic error. A semantic error is much worse than a syntactic one. At worst, a syntactic error leaves your meaning ambiguous. At worst, a semantic error leaves your meaning incorrect or inverted.
Usually you can read past a syntactic error, but a semantic error could change the tone or meaning of your entire message.
Usually you can read past a syntactic error, but a semantic error could change the tone or meaning of your entire message.
Well, it's a question of total value, weighted by frequency. If the autocorrection gets ten syntactic errors fixed for every one semantic error it introduces, it's probably a net gain for the writer.
One abnormally bad semantic error can be worth a thousand syntactic errors.
Have a little care, then. You have to be careful anyway with a touch keyboard. Autocorrect makes me faster, by correcting most errors without making me stop, and that's all I ask of it. I can't recall a time it's stung me in a major way; I can't count the number of times it helps me every day.
I guess we need a new entry in http://rubydramas.com
You know, this strikes me as very sane and cogent essay into maintainability and rails. Where does the drama come form?
To DHH credit, he always has fair points in his opinions, but the way he expresses these points is never diplomatic. For example, he couldn't resist making some blanket statements about java world and rspec.
I am not sure about how intentional that is, but it surely is dramatical in 'flame war eliciting' sense of word.
I am not sure about how intentional that is, but it surely is dramatical in 'flame war eliciting' sense of word.
The JAva point I felt was truly fair here. Servlets were good, but then it became the huge EJB which was bad. His rspec opinion - as expressed here that is - was "I dont like the DSL". Those seem fine really.
Just as a pointer I would recommend to get up to date with latest JEE specs and standards before making judgement
What I see is most people base their opinion on EJB2 from past and they keep ranting about that. Also java ecosystem doesn't start and end with JEE
Come on! They scrapped almost everything because it sucked and everyone knew it. Judging EJBs as a pile of shit is quite deserving. I mean this as a programmer who wrote Java code for a living.
OTOH, the servlet API is nice.
OTOH, the servlet API is nice.
DH2 critique in the Paul Graham pyramid:
http://www.paulgraham.com/disagree.html
http://www.paulgraham.com/disagree.html
Nope. He is criticizing based on consequence, which is the generation of pointless flame wars.
Presumed effect is merely fortune-telling. Xentronium said nothing about the java and rspec arguments themselves, just that something was said with what they think is an undiplomatic tone.
The notion that you cannot criticize somebody for the probable consequences of their actions is idiocy. Especially given the track record of DHH-driven flame wars in the past.
He also did say something about those specific arguments: that they were blanket. Which I took to mean: shallow and over-broad.
He also did say something about those specific arguments: that they were blanket. Which I took to mean: shallow and over-broad.
To whatever degree flamewars result here, they are historically not flamewars per se, but people arguing over tone. And I'm no statistician, but I would question the GP's probability calculations.
The way to avoid flame wars is not to feed them in anticipation, but to offer a critical beatdown of the arguments at hand, e.g. the higher levels of the PG pyramid.
The way to avoid flame wars is not to feed them in anticipation, but to offer a critical beatdown of the arguments at hand, e.g. the higher levels of the PG pyramid.
dramatic
If anything, this is deflation of previous drama.
Some related posts that probably spawned this article. You can find DHH's response in the comments:
http://gammons.github.com/architecture/2012/12/22/where-the-...
This talk (31 min, grab some coffee) also gives a better context. http://confreaks.com/videos/1125-gogaruco2012-mega-rails
This talk (31 min, grab some coffee) also gives a better context. http://confreaks.com/videos/1125-gogaruco2012-mega-rails
My understanding is that this article was in response to various questions that were asked of him on the Ruby Rogues Parley list (all guests are on the list, and others can pay to be on the list). Of course, recent topics he covered like hypermedia were colored by those recent discussions.
I think some clarity is in order.
While Java certainly isn't a pinnacle of language design, it took quite a few years of devolution to go from something relatively simple like servlets to the steaming pile of shit that is J2EE
I believe he means to say EJB here, and not J2EE, because Servlets are a part of J2EE.
While Java certainly isn't a pinnacle of language design, it took quite a few years of devolution to go from something relatively simple like servlets to the steaming pile of shit that is J2EE
I believe he means to say EJB here, and not J2EE, because Servlets are a part of J2EE.
J2EE's sins include far more than just EJB. See http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Editi.... Servlets got just started running with a bad crowd, even though deep down it was a good kid.
Personally I wouldn't let servlets off that easily. One of the basic design choices they made was one request handling function per class (the service method, delegating to doGet/doPost/etc for http requests). As a result, most applications actually needed another framework on top of servlets to do routing based on request URL and mapping on to some model of server side components, like MVC. See for example struts, spring, webwork and a host of other java frameworks that were around at the time Rails appeared on the scene. At the time, Rails' routes file and having classes grouping related controller methods together was a clear demonstration of what the servlet API had got wrong.
Heck, the architects even designed it as a completely generic request/response framework with http as just one possible protocol. When http is your 99.9% use case, that just smacks of over-engineering.
Heck, the architects even designed it as a completely generic request/response framework with http as just one possible protocol. When http is your 99.9% use case, that just smacks of over-engineering.
I certainly don't want to be one to defend Java from criticisms of overengineering. But on this point, I can't blame them much.
The Servlet spec was finalized more than 15 years ago, when CGI scripts were the mainstream server-side tech and browsers were circa version 3. The domain "google.com" wasn't registered until 3 months later. I think Servlets were reasonably well done for the time. The web was obviously dominant, but FTP was still widely used, and it certainly wasn't clear that newer protocols wouldn't be important as well. Rails didn't turn up until 8 years later.
One could certainly blame the java folks for stopping there, but there wasn't a lot of advantage to be gained from redoing the foundations in a way that forced everybody to rework all of their existing servlet code. And as you say, the community was making solid progress on their own, so it's probably better that Sun didn't interfere.
The Servlet spec was finalized more than 15 years ago, when CGI scripts were the mainstream server-side tech and browsers were circa version 3. The domain "google.com" wasn't registered until 3 months later. I think Servlets were reasonably well done for the time. The web was obviously dominant, but FTP was still widely used, and it certainly wasn't clear that newer protocols wouldn't be important as well. Rails didn't turn up until 8 years later.
One could certainly blame the java folks for stopping there, but there wasn't a lot of advantage to be gained from redoing the foundations in a way that forced everybody to rework all of their existing servlet code. And as you say, the community was making solid progress on their own, so it's probably better that Sun didn't interfere.
Oh, yeah - absolutely. The servlet API was very much of its time, and for several years it seemed to be a good solution. I think it's only in retrospect that it became more clear that there were key challenges that everyone faced in building a web application that the servlet API, and J2EE more broadly, didn't solve. For me that was the thing Rails demonstrated: a full stack solution for building web applications that actually tackled the real problems (like routing requests from URLs to controller methods). And I think the major changes to J2EE since have been in large part a reaction to Rails showing what problems a web framework should actually try to solve.
My mistake, you were intentionally casting a wide net. I see where you are coming from now.
In my time working with Java (14 yrs now...sigh) for simple Web applications, I've never found the need for the majority of the J2EE stack, instead opting for Servlets and...well, just normal Java code. I've had Java gurus throw proverbial books at me for not using EJB and its ilk, but I just don't like how complex it all gets once the full J2EE stack is included.
In my time working with Java (14 yrs now...sigh) for simple Web applications, I've never found the need for the majority of the J2EE stack, instead opting for Servlets and...well, just normal Java code. I've had Java gurus throw proverbial books at me for not using EJB and its ilk, but I just don't like how complex it all gets once the full J2EE stack is included.
Yeah, and I don't think he's been keeping up with Java EE 6 - EJBs are dead, long live JPA annotations. Of course, Spring is likely on borrowed time too. Just maybe we can lose the whole concept of a "framework", lightweight or not, that has kept those architects in business for so long.
why antagonism to architects ?
It is only developer which actually will think about implications of what is doing from more than one point. It would be nice if I see more developers doing that instead just coding big pile of ..(you got a picture I guess)
1980: "Another part of the necessary art of calling bullshit is to take down good ideas when they become inflated beyond what they can bear. Separating your code in functions that address single concerns is a reasonable idea that I support. But there's just not enough there there to dress it up in models, controllers, views, and all the other -- here's that word again! -- wankery that passes for muster in the MVC orthodoxy."
2010: (and this one's verbatim) "Another part of the necessary art of calling bullshit is to take down good ideas when they become inflated beyond what they can bear. Using URLs instead of IDs in your json responses is a reasonable idea that I support. But there's just not enough there there to dress it up in HATEOAS, HAL, custom mime types, and all the other -- here's that word again! -- wankery that passes for muster in the hypermedia orthodoxy."
I never could understand this attitude of overt antagonism towards people who care about architecture. If you aren't partial to such discussions yourself, at least show some respect for the people who, through years of wankerous discussion and debate, came up with and subsequently refined the pattern that propelled you to fame (or in the case of us mortals, at least gave us the tools to make our programming life a little easier). Now, I understand this particular guy is deeply invested in the MVC architecture. But that doesn't mean history stops here. REST (despite a long but somewhat underground history) and hypermedia are still in their infancy as an architecture. Many, many problems still remain unsolved and the process of debate meant to distill the good from the bad necessarily looks to outsiders as "wankery". Still, show some respect. The next person of Heinemeier's caliber will likely make their fame by bringing REST to the masses.