Configrity 0.10.2
Thanks tosbt-scalashim, Configrity is now backward compatible with Scala 2.8.1 and 2.8.2.
This is how a software community builds itself.
Thanks tosbt-scalashim, Configrity is now backward compatible with Scala 2.8.1 and 2.8.2.
This is how a software community builds itself.
This post was reblogged from implicit.ly.
Because you can’t put the Tabasco back into the bottle:
As my team navigated these waters, they would occasionally ask things like: “So this one guy says the only way to do this is with a bijective map on a semi-algebra, whatever the hell that is, and this other guy says to use a library which doesn’t have docs and didn’t exist until last week and that he wrote. The first guy and the second guy seem to hate each other. What’s the Scala way of sending an HTTP request to a server?” We had some patchwork code where idioms which had been heartily recommended and then hotly criticized on Stack Overflow threads were tried out, but at some point a best practice emerged: ignore the community entirely.
I feel I have a small part in this drama. That is, there is a Scala library for sending HTTP requests to a server that doesn’t use bijective maps (unless this is something one can do by accident) and that did exist last week, and last year, and the year before.
I understand why using Dispatch is out of the question for some people and I have no quarrel with them, or their reasons. But it is a part of the Scala HTTP story.
It goes back to my first open source project, in Java. I did some minor HTTP client work in it and was attracted by the idea of doing it far more expressively in Scala. This became Dispatch. I rewrote it about three times in the first year, and then again a while later. In that span I learned Scala, which was also the point.
My attitude with open source was that you should write whatever you want. You are working for yourself; anything that others get is gravy.
So I wrote an uncompromising interface for the way I wanted to code HTTP interaction, figuring that it would please some fellow travelers. And indeed, it has. The open praise for Dispatch is as effusive as it is rare. This was the plan all along.
What I wasn’t counting on was how much it would weigh down on me, again over the years, to have my humble offering relentlessly (and pointlessly, by the way) castigated by a rotating cast of characters. That part has sucked.
And I can’t help wondering, over the years and as Dispatch’s profile has increased (mostly by virtue of being “the maintained” Scala HTTP library), how things would have worked out if I hadn’t participated. Surely someone else would have filled the gap. But then, people have written alternatives–they just haven’t stood by them. No one can say if, in the absence of Dispatch, a more widely palatable HTTP interface would have been both written and maintained.
My hunch is, probably not. There are not that many fleshed out and maintained libraries in our community, in total. Because we are still small. Without one for HTTP everyone would just get by, the same way that many people using Scala get by without using a Scala HTTP library as it is.
If I were to do it all over again, knowing what I know now about software communities, I would do it differently. I would make a more conventional API because that would have been of greater benefit to the community. Whether that’s because most people are wrong, or I’m wrong, is beside the point. But it would be a little sad, because then some of us wouldn’t have had exactly the interface we wanted.
This commenter, reacting to a gloating post that embeds Coda’s leaked letter, explains Dispatch’s oddness as well as I ever have:
… the farthest we get from the world of conventional languages is using the Dispatch library to make HTTP calls as a client. This particular library takes advantage of Scala’s lack of operators, and ability to use operator-like method names to write some interesting things that would be.a.chain.of.dot.invocations.in most other OO languages.
I particularly like his way of referring to Scala’s “operator overloading” (necessary scare quotes, as it is nothing of the kind) because the why and the how of the language feature are right there.
Anyway, I suspect the actual state of HTTP libraries on Scala was never the point. Just ask yourself the same question for other programming languages.
What’s the Python (2.x) way of sending HTTP requests to a server? There are several different interfaces in the core library alone. Usually when coding something I’ll start with the highest level, easiest one, only to discover later that it can’t do the particular weird (or not so weird) thing I need, and I have to switch to a lower level one. This involves a little bit of rewriting because the interfaces are pretty different.
Or dare we ask: What’s the Java way of sending an HTTP request to a server? Back in the HttpClient 3 days most in-the-know people would have answered with that library. But then something funny happened. For version 4 they decided to do a total rewrite to address some fundamental issues in the library and also to better adhere to their ideals of software design. Problem was, it resulted in much more client code than the previous version, and a lot of users decided never to migrate. Correctness by some standard was achieved, but the user base became disenchanted and drifted away. (Sound familiar?)
So I don’t think the point could be that Scala is uniquely devoid of one-size-fits-all solutions, or uniquely subject to disagreement over the best idioms. Every language struggles with these, to varying degrees. Surely no one coming from Java has forgotten, already, the “over-architecting” that is widely derided outside of Java. Surely if the worst thing a troll can compare Scala to is J2EE, that tells us something. And let’s not get started on the upside-down church of IoC, which surprisingly held sway over a good chuck of the world’s most stolid software development shops.
The real difference from Scala is, if you ask in a forum what is the Python or Java way of sending a request to a server, you may get different answers but you won’t get people savaging each other or the choices presented. Usually. Within those languages, which also happen to be a lot older than Scala, there are pools of consensus around evidently useful libraries and people aren’t in the habit of declaring any of them as strictly invalid. It must be nice.
~~~
But I have not really reacted to the letter as much as contextualized it. Around myself, rather selfishly. This is what people do in blogs.
What I think is that Coda’s team’s earlier withdrawal from the Scala community–a decision to ignore it entirely–guaranteed its eventual withdrawal from the thing the community was about. Scala.
I suggest that this is true in general. People who don’t socialize with any of their co-workers will leave a job. People who don’t make friends in a new town will move “back home”. We’re social animals and we can’t function otherwise.
We’re also practical animals, and going it alone on a software platform doesn’t make a whole hell of a lot of sense.
I agree with some of Coda’s feelings about the community. I have never really participated in any of the general Scala mailing lists, if that gives you any idea. But it’s nothing particular to Scala; I’ve seen the same behavior on any technical list that gets large enough. Actually, I saw the same behavior in high school, except it was dumb people beating up smart people (mostly). On technical lists it’s the really smart people beating up the smart people. It’s the same urge to dominate, or simply to exalt oneself.
Building a healthy community in Scala is harder because the language draws in people from the top tier of software and computer science. It’s a personality match made in hell (even though we’re all such fabulous individuals), and we see the predictable results every day. We can try to carve out little safe spaces, but ultimately, the internet defies segmentation. You can’t avoid finding what is wrong on the internet, and you can’t sleep until you said so. (And then, you still can’t sleep, because you are QAing your arguments in your head–or maybe that’s just me.)

I’ve decided to devote my time to a local, face-to-face Scala community which I see as the best antidote to this poison. Some of the nastiest nerds become lambs when they meet in person. And the really cool thing is, the civility carries into the virtual realm. (Did I just say “virtual realm”? It’s getting late here.) If you see people often enough, and know that you’ll see them again pretty soon, calling them a retard on some forum becomes decidedly less gratifying.
Coda was kind enough not to advise others what language to use and I’ll return the favor. I have no idea what his team should do and it’s none of my business. But for everyone, and any technology, participating in the community is a prerequisite to long term success. If things are not working out people-wise, things are not going to work out period.
We’re doing our best to make this thing better. Care to join?
Were you annoyed because the old Dispatch and Unfiltered forums did not have a Google+ notification bar at the top of every screen?
Fixed that for ya!
“The Scala IO umbrella project consists of a few sub projects for different aspects and extensions of IO. The core project deals with raw input and output, primarily through streams and channels (at least the Java implementation).”
— Scala IO