I think the bottom line remains this: Cloudant gets to choose with whom they do business. They, and pg, were both proud of the fact that they chose Monsanto - I think this exactly the kind of thing that 'the 99%' are protesting

I so wish this were the top comment.

That's really the issue for me. Most of the analogies with Apple/Microsoft/Chevy/etc. are flawed because anyone can buy those products. In this case, Cloudant not only accepted a partnership with Monsanto (and thus, obviously had communication with them for some time) but touted it as as the greatest thing since sliced bread.

And I can understand their enthusiasm since it's a big deal with regards to their business.

But, Monsanto's track record within the last forty years is deplorable. Read their Wikipedia page, about Bovine somatotropin, or watch documentaries about them. Goodness, it's hard to like them.

by the way, the original article (now) opens with "Algorithmic trading, including high frequency trading (HFT)" and not "Algorithmic trading, also known as high frequency trading (HFT)"

"Without having to live in a dorm" ... I thought living in a dorm was the best part of college.

Then you didn't live in a building full of 200+ proto-adults, many of whom lacked bsaic cleaning skills, long enough... or maybe I just lived in one too long :)

oh man, can't wait to use closures in my Java code

Unfortunately, you'll have to wait (until Java 8).

I work for PLoS, it's great to see Open Access become such a high profile subject after the aaronsw story

Out of curiosity, what do you do for PLoS?

Yea, I think you can ask it in a way that's not abrasive - "Do you feel like you have enough interesting work to do?". I think the thing is that that can be a common question, and it lets people know you care about how engaged they are.

Aren't singletons the whole goal of Spring?

Dependency injection frameworks/IOC containers (pick your stupid name of choice) avoid at least one of the problems of singletons: if you decide that you don't want it to be a singleton any more, you can trivially change the lifecycle to 'instance'.

By contrast, using singletons in plain old Java, you'd have to go through and find every usage of SingletonClass.instance().everyMethodCallOnThisClass() and push it up to the constructor. Since you now have a new dependency you have to pass all the way down your callstack, it can get painful quickly.

You still have the issue of global state, but I think that's altogether more complicated. Sometimes state really is global to your program and exposing it everything makes a certain amount of sense. It may well be ok for managing system resources (thread pools, network connections, IO in general). I think often you can get away with a boolean flag or two shared across a whole app. If it's read-only it's not a problem at all.

You need to be aware that every bit of shared state you make available or continue to use is a potential source of bugs and maintenance. Every bit of this that you expose needs serious thought. Don't let it snowball. Even if it means you have to make a few extra types of object or pass a stupid number of arguments all the way down the callstack, that's usually preferable because at least then you can reason about what's going on.

And with structured programming, it's only one extra argument per function call, StuffThisFunctionNeeds (plus a structure definition for each different flavor of StuffThisFunctionNeeds)

Not at all. IIRC, default instantiation mode is one instance per injection.

Actually I think singleton is the default: http://static.springsource.org/spring/docs/3.0.x/spring-fram...

I didn't know about the other scopes though

What is Spring?

Second hit on Google: http://www.springsource.org/

I don't think the author is to blame at all. I do stuff like this all the time - I'm working on something, google for it, download and keep on moving. I use google constantly throughout the day, and trust the top result to be authentic. As it turns out, that trust may be unwarranted.

That's the point - you don't learn the whole stack, you let your framework manage it.

This is one of my problems with younger developers. They slap framework code together rather than actually figuring out what's going on underneath.

It's one of the reasons I still use PHP. It's the perfect balance between framework and coding.

It's not about being able to add code to every piece of your stack, but understanding what all of its external interfaces do. How many programmers you know can do that with their stacks?

There a lot of powerful frameworks in Java that make application development fun and easy (e.g. Camel, Spring, Hibernate). Java can replicate many of the popular features of other languages - anonymous functions are duplicated by single-method interfaces and anonymous inner classes. I say use the best tools available, and Java has still got to be one of those.