Mending the Bitter Absence of Reasoned Technical Discussion | Hacker News Reader

Mending the Bitter Absence of Reasoned Technical Discussion

al3x.net

69 pointsmadmotive51 comments

Internet discussion, quite frankly, sucks. It's driven by emotions and not logic. People are crass, rude, and take snipes they'd never do in person.

It used to be people wrote long letters to each other, like with a pen and paper. In that format, you had to make a case and defend it. In the new format, if you're writing more than 3 sentences you're a regular Tolstoy. The format has gotten shorter, the response time more immediate, and the audience less educated.

I remember when C++ was finally overshadowed by newer languages like Java with fancy IDEs.. Old timers quickly found a lot of complete crap coming out from programmers who never had to do things "the hard way" If you never had to take the time to think about classes before you wrote one, everything is a class.

Likewise if you've never had to take time to think about what you're writing before you comment, everything is a short, knee-jerk response.

Combine all of the above factors and you get an endless stream of tripe. It's the uneducated talking to the uniformed about topics that make them unhinged.

It's interesting that somebody associated with Twitter would make that observation. The format keeps getting shorter and shorter, and the time frame more and more immediate. Can't he see the connection?

I can see the connection, but I myself don't use Twitter that way. I write a full blog post of content, then edit down to 140. It's surprising how little needs to be said to make a point, when it comes down to it, and how strong a point sounds when it's been compressed that far.

Yes, that's really what good writing is about, get anything written and then revise, revise, and revise.

I recently discovered this cross posting feature posterous has with twitter, so if one has the distilled post down to 140 and then puts that as the subject, readers who don't see the depth of the point and/or just wish to hear more can link to the full version. I think you've touched on a nice approach to using some of these new tools to improve the quality of communication.

tl;dr

No, just kidding. People have been speaking in short sentences for a long time. Your model is too simplistic - writing letters is a less a discussion, and more debate. Ordinary everyday conversation is shorter, and possibly, more inane.

With discipline, I think, and an appropriate community (like Alex mentions) reasoned debate and discussion is possible, without writing pages and pages. See, for example, HN. (Yes, people write comments of this length on other sites, too. No, they aren't always as reasoned.)

Not all internet discussions are like that, and in-person discussions sometimes are like that. Long letters were always very rare; a prolific letter-writer in the 1800s might have written hundreds of them in a lifetime, but a more typical number might be ten. I think the majority of human discourse throughout the millennia has consisted of things like schoolgirl gossip, parents scolding their children, "ain't-it-awful" discussions in bars, and requests for phone numbers shouted over loud music in dance clubs. What you're observing is that more of that stuff is being done in writing instead of by voice.

People do seem to be more willing to disagree with each other on the internet, but that doesn't necessarily worsen the quality of the discourse.

So all that has happened is that the Internet has allowed schoolgirl gossip and yelling in bars to be broadcast on an international scope and compete with professional journalism and scientific discourse. I suppose that cannot be helped with the democratization of the media. Still, if the common man is going to have that kind of power, should we not urge everyone to use it responsibly, and to try to raise the level of discussion, especially in what is supposed to be a professional context such as software development. Of course, that is what Hacker News is attempting to do; I'm hoping it will work.

The way I see it is that the internet has allowed professional journalism and scientific discourse to compete with schoolgirl gossip and yelling in bars.

One problem, though, is that the needs of these forms of communication aren't really the same. In a low-latency medium, for example, it's difficult to avoid strong structural biases toward both recency and immediate responses; these are both corrosive to the quality of the discourse. (I think these structural biases mostly account for the very low quality of professional journalism, but they are even stronger on e.g. reddit or HN.

pg and I have written some things about this:

http://lists.canonical.org/pipermail/kragen-tol/2008-January... http://paulgraham.com/hackernews.html (under "Fluff Principle" and "Comments")

I find the comment on C++ interesting. Having worked in Flavors/CLOS on Lisp (Lisp is slow was a criticism then also), I found C++ a step backwards not realizing that at the time C++ was just an attempt at codifying what programmers were already doing with macros in C. But with C++ a lot of what OOP was meant to be was lost. Java was somewhat of an improvement, GC, single inheritance, etc.

C++ didn't really lift the programmer away from the machine, so poor programmers who never learned proper memory management, etc. could cut themselves up pretty badly. Coplien's book on how to do symbolic programming correctly in C++ was a positive development but I suspect likely lost on most C++ programmers.

I couldn't agree more with your comments about the quality of discussion. I can only add that as an older programmer I'm also disheartened by the ignorance of history. In my generation calling someone a dirty hippie was fighting words and I had thought we had learned to be tolerant of others. When I see the vicious and nasty remarks people make about Richard Stallman I can only surmise that they have no clue as to the work he has done on the tools that we use daily. Emacs is crufty and shows it's age but contains a lot of fantastic ideas that have made it the timeless tool it is.

But this is human nature. My mother used to tell me to never say anything to or about someone that you won't say to their face. I plan on pointing this out to this fellow Zed Shaw should I ever have the pleasure of meeting him :)

So, it's actually relevant to the topic to point this out: Once you meet Zed Shaw you will realize that he may have been trying to write like he talks. It just didn't work very well. Zed Shaw in person is a hilarious, charismatic trash-talking New Yorker who is also an intense hacker genius. If you understand both New York-style trash talk [1] and intense hacker geniuses, you will understand Zed Shaw. He seemed like a nice guy, the couple of times I met him.

But the trash-talking aspect of his personality doesn't translate well to a text-only online persona. The body language and expression and tone and intensity and back-and-forth are all lost, as is the context: He can't tune his approach to his audience, because he doesn't have any feedback.

He seems to have figured that out now and is making a deliberate attempt to change his online persona.

One big problem with the internet is that you must develop a completely different online voice from your offline voice if you don't want your words to be taken the wrong way. Your work online is decontextualized in a way that your own words are not.

---

[1] Try to remember that when an East Coast working-class person says fuck you they very likely mean "have a nice day". Though it depends on the delivery.

"One comment that seemed particularly uncontroversial to me was at the core of this nerd firestorm: Ruby is slow. For the next several days, I could think of only one thing: why is something you can measure controversial?"

This is exactly what needed to be said, and repeated until it is fully and widely understood. Cognitive dissonance should not be assuaged at the cost of the rational and empirical.

The regexp engine isn't slow. The bignum support isn't slow. The development time isn't slow.

If you wonder why there's a firestorm, it might be because of sweeping generalizations.

No, you're completely dodging the issue by saying some library functions, not written in Ruby, are not slow, and then talking about development time, which has nothing to do with the slowness people are talking about. The last time I checked, we're talking about the speed of code written in Ruby, and in particular, the speed of code as it's typically written.

The regular expression engine and large number support are simply not broadly representative of Ruby performance, and do little to refute empirical observations of properly representative benchmarks and the many educated critiques of Ruby's implementation.

Your final example of development time is wholly unrelated to runtime implementation performance, and its use as a justification to assuage cognitive dissonance is predicated on a false dilemma -- that a language can not both support rapid development and a well performing runtime.

It is not necessary to introduce a false dilemma to justify an individual preference for Ruby development, in spite of its measured performance.

Isn't that a lot like saying that despite the VM system, OpenBSD 2.1 wasn't slow because it had a pretty good "gzip"?

Python is slow. For loops containing arithmetic, array indexing, function calls, and similar primitive operations that also exist in C, it's maybe 100× slower than C. But programs written in Python are usually not 100× slower than C programs with similar functionality. They may be 10× slower or 3× slower or, very rarely, faster; that's because their inner loops tend to be in operations like regexp matching, array arithmetic, data compression, string hashing, and the like, and Python's implementations of those things aren't themselves written in Python — they're the things you're likening to "gzip" here.

There's a selection bias here. If you write your compiler or interpreter or pathfinding algorithm in Python, it's going to be a lot more than 10× slower than if you wrote it in C (or Java or OCaml or whatever). So people don't write those programs in Python, so we don't get to compare them.

I've been writing about Python because I know more about it than I do about Ruby, but I think most of the same things are true of Ruby, as well.

Sure -- minimizing the number of Python statements is a decent optimization heuristic in Python (and, as a bonus, that can help you optimize for human readers as well when not taken to extremes).

PR, marketing and politics are facts of life. The reasons that Ruby/Rails community ridiculed (obviously accurate) "ruby is slow" are exact same reasons the community was such a success in the first place. Consider what would have happened if "ruby is slow" meme took off. Forget the RoR itself, but it would have actually been a disservice to users who don't understand the details and wouldn't have been able to make the right choices.

If you actually want to affect a change with communication it's useful to think through what, where and how you say it. But mostly, don't just complain, include a patch. E.g. our Ruby and RoR patches were accepted the same day with gratitude: http://blog.pluron.com/2008/01/ruby-on-rails-i.html

We (Pluron/Acunote team) are going to be presenting @ RailsConf 2009 ( http://en.oreilly.com/rails2009/public/schedule/detail/8615 - Advanced Performance Optimization of Rails Applications ) and it's going to take some work to frame the presentation in a useful fashion. As tempting as it is just to point out how bad every single part of the stack is, from our hosting to Firefox, it would be highly misleading; they are still the best available options.

Having said that, it's a pleasure to have HN where these sensitive topics can be discussed in a rational fashion.

I do not believe that forthright explanations of genuinely complex topics can ever be a disservice to users -- accurate and complete information is critical to "make[ing] the right choices".

The suggestion to provide patches is a simple displacement mechanism. A correct, reasoned evaluation is not predicated on also including patches, and a reasoned evaluator may have significant cause to not invest further effort in providing improvements to the evaluated software.

I agree with you, but I think the gp has a point: look at Java as an example. Here we are, at a point where Java code runs extremely fast, but because of the "Java is slow" meme that took off at the turn of the century, any time Java comes up you _still_ see uninformed people on (for instance) Slashdot insisting that Java is unusable for important code because it's so slow.

That said, I don't think the right solution to avoiding problems like this is a "head in the sand" approach. If there are real performance issues, they should be acknowledged and addressed. I definitely get the sense that a lot of Ruby zealots are trying to pretend that there is no problem, which is something that Java zealots tried to do years ago (and something that the people in control of feature requests still do quite a bit, using the "Nobody can microbenchmark the JVM, it's too smart!" excuse).

I don't know why this stuff gets people so emotional, though. You don't see carpenters have heated arguments about whether a screwdriver is better than a hammer; why do programmers get so emotionally attached to their tools, refusing to acknowledge the limitations and strengths of each particular one?

Obviously, some language/OS/etc cultures are more fanboyish than others. I tend to not get active in those; it'd be embarrassing.

Edit: I am specifically thinking about Ruby here. It seems quite neat and worth trying, but... Maybe I'm spoiled with polite communities.

I can think of two reasons getting emotionally attached to the tools: learning the tool, be it Java or Ruby, requires considerably more thought than learning to use a screwdriver and using the tool shapes the way problems and solutions look to a programmer.

Required effort causes programmers to know less languages and to value the languages they already know higher as they've had to come up with a rationalization for learning the language. This rationalization hinders acknowledging the downsides of the languages they've learned.

Additionally, languages give us our vocabulary and solutions seen beautiful by a programmer of one language can seem incomprehensible or at least ugly to programmer of another language. This is at least something that I've personally observed in a Java-shop I work in.

People still get emotional over primitive tools. Having an emotional stake in the tool must have conveyed some evolutionary advantage as we all display it.

The reasons that Ruby/Rails community ridiculed (obviously accurate) "ruby is slow" are exact same reasons the community was such a success in the first place. Consider what would have happened if "ruby is slow" meme took off.

Sadly, there's no standard and acknowlegedly forceful way to say: "Your statement is technically veridical but I disagree with the connotations you intend to sneak in."

http://lesswrong.com/lw/4h/when_truth_isnt_enough/

Nice exposition of the idea, thanks. In the vernacular, isn't it just "attitude" and "tone"? It's also possible to not intend the connotations, at least not consciously.

My language is powerful; yours has dynamic binding; his is slow.

Sadly, there's no standard and acknowlegedly forceful way to say: "Your statement is technically veridical but I disagree with the connotations you intend to sneak in."

Yeah, there is. You yell. That's why cable TV news shows (and politics in general) suck so much -- you get two sides who refuse to actually contradict each other competing on volume to have their message triumph over the other.

That's because most of the people watching are going to come away with one idea, and you want those people. If you want to "win" in the minds of those simple-minded people, and your opponent isn't saying something that can be easily falsified, you have to compete on volume, arrogance, and ferocity.

On the other hand, if you only care about the viewers or readers who are capable of having a nuanced view, you can simply say what you have to say, as clearly and cogently as you know how. They'll understand and remember. But will you really be satisfied with those people? Probably not, if you're fighting for votes or market share. In other words, unless all you want is a fair shake from intelligent people, what you want can't be had in a civil way.

until it is fully and widely understood. Cognitive dissonance

By accusing people of "cognitive dissonance" and apparently believing that's the primary issue here, you are contributing to the drama.

See the comments on the original:

http://www.radicalbehavior.com/5-question-interview-with-twi...

The aggressive and insulting remarks directed at Ruby, Rails and people associated with them are exactly the source of the problem here.

Ruby is slow. Fast, good, easy - pick 2.

A false dilemma.

Explain with examples?

What technical limitation prevents a language from being fast, easy to use, and well designed? Alex seems to argue that Scala is 'fast, good, and easy', and I would tend to concur.

What I've seen of C# 3.0 and F# also implies that those languages could meet this criteria, but my experience with them is limited.

Software engineering is about tradeoffs. I'll take that a step further: everything is about tradeoffs. You can always optimise for one use case to the exclusion of the others.

Are you saying that fortran isn't faster than scala/jvm based languages? That APL isn't better for matrice's? That lisp macros aren't more powerful? Or that php isn't simpler than scala?

Being good at all three may be possible, but being optimal at all three is probably impossible.

"Being good at all three may be possible, but being optimal at all three is probably impossible."

Why?

http://en.wikipedia.org/wiki/Optimization_(mathematics)#Mult...

"Multi-objective optimization (or programming),[1][2] also known as multi-criteria or multi-attribute optimization, is the process of simultaneously optimizing two or more conflicting objectives subject to certain constraints."

Note "conflicting objectives". Why do you believe the objectives are conflicting?

Let us see how PHP and Ruby compare out of the box versus Java:

First PHP vs Java: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Now Ruby 1.9 vs Java: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

And finally Ruby 1.9 vs PHP: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

So, both PHP and Ruby 1.9 have a hard time when trying to keep up with Java and in these tests Ruby seems to have an edge over PHP. Not to mention that Yahoo one of the biggest enterprises on the web uses a lot of PHP for their services, but there are ways to further optimize PHP so who knows what each user can do to improve performance.

My point in bringing PHP into the spotlight is just to show that there are other languages that a priori were just as slow as Ruby but given their niche have had enough success to endure "slowness" criticisms.

The languages that are considered fast have often to face potent competitors which make for an immersive experience seeing them develop in the marketplace. Ocaml what, I hear you say?

Ruby 1.9 is a big improvement over Ruby 1.8, but last I heard, a lot of people still had to use 1.8. In six months maybe "Ruby is slow" will no longer be a valid argument for PHP over Ruby, but if you're using Ruby 1.8, it's still valid.

PHP, and I say this as someone who thinks it's awesome, isn't so much a language as a way to glue together a bunch of C libraries, so its speed isn't that important.

One of the reasons Ruby 1.9 adoption is so slow is that the people who really needed speed have long since moved on. 1.8 is still good enough for most of us who use Rails every day.

The following line in the post is the crucial thing. "Amazing how suddenly reasonable and transformed a person can be when they’re forced to look you in the eye"

And I think a version of that is included in the guidelines for HN. The power of Internet conversation is the 'detachment' which can work both ways. It can get the nerdiest of nerds to get to talk to large audiences without inhibition and thus contributing to the society at large. However, it can also get them to show their nastiest sides, which probably would have been hidden but for the detachment provided by the medium.

Unfortunately, the thoughtful, intelligent, facts-minded individuals are vastly outnumbered (or at least, out-shouted) by trolls and fan boys on the Internet. Even more discouraging is that the latter are the least likely to read an article like this and take it to heart.

I think one of the problems Alex is pointing at is when thoughtful, intelligent, facts-minded individuals act like trolls and rabid fanboys, for example when their favourite programming language or text editor is mentioned in less-than-glowing tones.

(P.S. emacs sucks.)

I suspect that many smart people do not troll but engage in a marketing game to preserve the status quo. It keeps the attention focused on the current leaders, away from newcomers that could potentially disrupt the status quo. Often the products or technologies of both sides resemble each other a lot. Their commonality is much larger than their differences.

FTA: "And so we roll our eyes, sigh, and quietly accept the idiocy, the opportunism, and the utter disrespect for our peers and ourselves that is technical discussion on the Internet."

As a great thinker once said, "I'm starting with the man in the mirror."

Ruby is a particularly strong magnet for this kind of controversy. As he notes, many of its strengths are not easily quantifiable, while its weaknesses are. Add in stereotyping, tribe mentality and cynicism and it creates drama.

Sure... Nice write-up.

From the Hacker News site I have been following the recent controversy and even participated in some discussions. :-) Your Honor, I plead guilty! :-)

I cannot blame them (Twitter) when they seek their goals for a better business with higher quality and performance. I even respect their creative skills. So I don't have a beef with them even when Ruby gets caught in the polemic.

Ruby to this day continues to be an open source project put together by a community that for better or for worse has most core developers being Japanese.

But since about 3 or 4 years ago, Ruby has had other developers seeking to implement compatible Ruby versions... That is, Ruby has outgrown itself and continues to do so. JRuby, MacRuby, Rubinius, IronRuby...

At the end of it, though, Ruby continues being relatively slow when compared to other kinds of languages. But first read the following article to see some reasons why is that: http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...

Since Ruby's beginning, it was not out to reach C level performance. And JRuby for one improves upon some of the shortcomings of the main C implementation of Ruby quite well, not without its own shortcomings though. :-)

So, what do we have in the controversy? Twitter is a little sick of complaints of it letting the ball fall when much more is required of their services, so they go overboard when defining a solid platform for it with Scala. Not to mention that they simply can't go converting their entire system to Scala just yet and they are still happy with the Ruby part of the equation at creating the web interface the users see.

What do we have then? More options of development. Instead of C, C++, Ruby and Java, include Scala there as well. Each with their own pros and cons. We know that, right? But if it were simple to use each one of those languages and more when providing a set of services, we would not have a beef with who chooses what when developing. Nature has it that while it's possible, it's much tougher to get it working. That's partly why big companies like Google try to minimize their options of tools and in doing so help to set standards throughout the industry.

Such standards, fortunately, don't apply for everyone, otherwise Twitter might have started with something other than Ruby on Rails.

The part of this essay ( or blog writeup ) on How To Have A Reasoned Technical Discussion can be put up on the HN guidelines maybe !

Very good article. This should be right up there with famous articles such as "How to disagree" and many others. I think this should be required reading for many of the technology blogger equivalents of political bobbleheads out there.

For deeply technical conversations I research answers I give and back up what I say with links to source material or a log of the commands I ran. This seems to be quite unusual, and I believe most technical discussions would benefit from a similar approach.

There Is More Than One Way To Do It - TIMTOWTDI - it's a pity that that slogan is confined to the Perl community. No other slogan is so effective in imposing a culture of civilized dialog between competetive projects.

A breath of fresh air.

Bah! Reading all the bickering on this page about a blog entry about bickering has been a huge time-suck, including formulating this response. If you have come across this comment please leave before it's too late!

Well it's Sunday morning here, beats going to church :)

Reply on news.ycombinator.com