Are you insinuating that kdawson would deliberately change a story title to be inflammatory and sensationalist!? Perhaps if kdawson had some sort of long history of trolling Slashdot with badly written articles I might be inclined to believe you!

Piracy is a term used to refer to copyright infringement, not theft.

It's idiotic because the use of violence to rob ships at sea, is rather different act than copying data without the author's permission.

No you don't. You're confusing security with authentication.

It's idiotic, but not a recent term. Unauthorized distribution of content was called "piracy" as far back as 1603.

Tor is a service for browsing anonymously, not securely. Security is handled by SSL.

Aside from a few edge cases, FF is generally faster than IE8, especially for sites that make heavy use of Javascript.

You seem to be assuming that just because some countries are getting richer, others must be getting poorer. Global wealth is not a constant.

But Stallman does not develop the Linux kernel; Linus Torvalds does. The lack of a stable ABI is not for religious reasons, but for technical ones.

The HTC Hero is pretty comparable, though. It's got a slightly less powerful processor, but it's slimmer and has a better touch screen, and like the N900 supports Flash video.

What would you propose I measure?

I've programmed in Java with a number of IDEs, and yes, the refactoring tools are extremely useful. But I also found that I didn't miss them much when I programmed in dynamic languages. It's my opinion that the very attributes that allow Java to be easily refactor, i.e. its restrictive and rigid syntax, are the very attributes that ensure you need to do a lot of refactoring work in the first place.

Secondly, even if we accept that being to easily rename things is an equally useful trait in any language, then I'm still not convinced that good refactoring tools are a cost that is worth Java's terrible syntax. At best, refactoring tools make hard things easier, but Java's syntax makes some solutions infeasible.

In other words, you're saying "In order to make naming easier, I'm going to make these classes of solution infeasible." In my view, this ain't a good trade-off.

I never said it was. My first example was an attempt to show that Clojure's syntax and basic data-structures support loose-coupling in a way that Java doesn't. My second example, the one you object to, was supposed to be an example of how Clojure's supporting libraries all tend to be loosely coupled.

I guess my example wasn't very clear. Here's the source-code of the read-lines function in question:

(defn read-lines [f]
  (let [read-line (fn this [#^BufferedReader rdr]
                    (lazy-seq
                    (if-let [line (.readLine rdr)]
                      (cons line (this rdr))
                      (.close rdr))))]
    (read-line (reader f))))

The read-lines function doesn't care what the type of its argument is, so long as it can create a reader from it.

The Java standard libraries don't do this because Java's type system isn't sophisticated enough to do this with any type safety. I guess you could use switch statements and casts, but it would be unusual to see such a design in Java, and counter to its culture.

I haven't really had a problem with this. In all the projects I've worked on, there doesn't tend to be much disagreement over technology. We get into very detailed discussions that can last for hours, but we almost always come to an agreement as to what to do. Even when developers can't agree, there's always a project lead to make the decision, and in that case everyone goes with the decision and moves on.

That's not quite what I mean. Whilst Java provides keywords to enforce loose coupling, its syntax and standard library don't make it easy to do so.

For example, in Clojure I could write:

(defn bag [coll]
  (reduce #(merge-with + %1 {%2 1}) {} coll))

The collection we're going to turn into a bag could be any sequencable data. In Java, you could use generics, but you wouldn't be able to treat, say, strings in the same way:

=> (bag "hello")
{\o 1, \l 2, \e 1, \h 1}

Here's another example:

(use 'clojure.contrib.duck-streams)
(def words1 (read-lines "/usr/share/dict/words"))
(def words2 (read-lines "http://www.puzzlers.org/pub/wordlists/pocket.txt"))

In this case, the duck-streams library is equally happy reading lines from a file or from a URL.

In other words, functions in Clojure, like many dynamic languages, usually pay more attention to the traits of an argument than to its type. Java's type system isn't flexible enough to do this on the same scale, and Java's standard types are also too inconsistently structured.

Measurements based on one project aren't exactly statistically robust. Especially if this is the first project your team has written in Scala, as your post would seem to imply.

I haven't used Scala for any considerable project, but I have written a lot of Clojure, and my experience with Clojure is the opposite to yours. I find code written in Clojure tends to be considerably more maintainable than any code in Java or C# that I've been involved in supporting.

This is partially because the source code is much shorter than it would be in Java or C#, and partially because functions are much more loosely coupled in a dynamic language.