daniel_solano

I don't have the time to read the whole article, but here's a few thoughts:

Regarding On life, property and personal security, this section is about violent crime in the U.S. Indubitably, violent crime is particularly bad in some parts of the U.S., but is this part of the 'human rights record' of the federal government? In essence, the Chinese government here is implying that the fact that the U.S. government doesn't outlaw gun ownership results in violent crime.

Throughout most of the text, it just strikes me that the notion of what constitutes "human rights" is unclear. Some people believe that human rights are about the recognition of individual liberty and freedom from government intrusion. Others believe that human rights are about achieving equality and freedom from want. The Chinese government is certainly sympathetic to the latter definition, at least in this report. While this is a point of view favoured by many, in the U.S. the former view of human rights is still strong.

Finally, some of the points made by the Chinese are simply symbolic. For example, they criticise the U.S. for not ratifying the "Convention on the Elimination of all Forms of Discrimination against Women (CEDAW)". That is true, but the U.S.'s laws and enforcement are considered better than China with respect to CEDAW.

On the other hand, if they sell the stock to the public at $38 and it drops down to $34, it's someone else that's out the $4. Sure, it may create some temporary negative publicity, but, as you stated, they will recover.

1. Hired a PR firm in an attempt to threaten TED into publishing his talk. 2. When that failed, he misrepresented TED (by selectively quoting private correspondence) to the media in order to create the subsequent firestorm.

I will accept that the speaker may be passionate about his views. However, he is not interested in open discussion, at least not if you mean honest by open. The ends does not justify the means.

1. He often made more money from the ad-supported free versions of his games rather than the paid versions.

2. The Play Store is not the only place to download/pay for Android games. According to him, there are hundreds of alternative markets (such as Amazon's), some of which are much more prevalent outside the U.S.

1. It's not entirely clear how to use this. Is XobotOS a replacement for Android, or is it something that can be shipped as a standard application? In my limited time reading the documentation on the GitHub page, this was not clear to me.

2. It looks like a it is a terminated research project, to quote the README:

This code is provided as-is, and we do not offer support for any bits of code here, nor does Xamarin plan on continuing evolving XobotOS at this point.

From the blog post, it sounds like they are integrating some of this technology in their products, but XobotOS is otherwise just a code dump. As such, unless someone is really interested in this, it doesn't seem like it's going to go anywhere.

In my experience, most of the alternative compiled JVM languages, i.e. Scala, Clojure, Mirah, and JRuby, seem to run fairly comparable to each other once they have started. The biggest differentiator between them with respect to performance seems to be in the way of start time and heap overhead ranging from none (Mirah) to substantial (JRuby).

My understanding is that there is greater interest in making Clojure more suitable as a library and with a leaner runtime requirement. If you have a situation were you don't need a dynamic environment, having the option to compile functions to static methods instead of classes should result in a big performance increase.

I have only briefly looked at Kawa Scheme, but I have not had the time to do much with it beyond a "Hello, World!" sort of project. Mirah is another interesting option. It uses a Ruby-inspired syntax but requires no runtime library.

The main drawback to Clojure is still the start-up time, but that's getting better. For example, the metadata elision introduced in Clojure 1.4.0 speeds things up a bit and makes a significant cut in Clojure’s heap use.

However, one thing that Clojure gives you that Scala cannot, is the ability to do REPL-driven Android development, i.e. sending code directly from your editor to a running application and seeing nearly instantaneous results.

One thing I hope will help Clojure significantly is that it has a Google Summer of Code student who is going to be working on improving the tooling support for Android and Clojure. This should make it much easier for Clojure developers to start creating Android applications.

Honestly, I have no idea. In the end, these levels are primarily oriented at companies or other groups (education?), not individuals. What's one person going to do with 25 licenses?

If I recall correctly, according to the director of IT of a large, local non-profit, they get access to the full suite of enterprise Microsoft products for something on the range of $1000 per year.

At that price point, saying 'open source can save you money' is meaningless, because they have already made investments in Microsoft IT expertise.

Although female programmers are rare now, that wasn't the case in the 70's. That shift is another argument against the natural balance hypothesis.

I am too young to know, but is this the experience of others as well?

Again, this is based purely on anecdotal experience, but I wonder if women programmers tend to concentrate into particular industries (for whatever reason). My wife was a programmer at a contractor for a large government agency, and it struck me that there was a higher concentration of women there than in other industries or in the start-up scene.

If this is generally the case, I am not sure to what extent this would support any given hypothesis.

I disagree. I think it only has to do with Romney's status as the front-runner. Romney portrays himself as a businessman that knows how to create jobs. Newt is trying to paint Romney as an 80s-style corporate raider. I am fairly certain OWS has nothing to do with it. If Newt was the front-runner, he wouldn't be bringing it up.

I think what is meant by safe in this context is that an that is not an input method cannot pretend to be one. Likewise, the interface between the input method and applications means that an application cannot normally wire itself into the input method and monitor everything the user types.

Now, there have been some source-level incompatibilities, especially going from Clojure 1.2 to 1.3, and this seems to have been a bit of a headache within some parts of the Clojure community.

Apple, on the other hand, decided that a touch-based interface was the way to go. As such, Apple designed iOS to make rendering in a special, real-time priority thread to ensure responsiveness.

One example where something was impossible in Scala is that to implement a Parcelable for Android. This requires the creation of a static field, which Scala doesn't allow. Now, I won't argue that an API that requires such a construct is good, but it might be necessary for your application. I believe Scala now contains special code in the compiler just to support this peculiarity in the Android API.

I don't deal with training a team of developers, nor do I have to integrate with enterprise-scale infrastructure, so those things just don't apply to me.

What are the benefits of Scala? I can think of a few, off-hand:

1. Traits: I really like traits and the way that you can use them to encapsulate cohesive and reusable functionality. In some ways, traits allow you to do a form of aspect-oriented programming.

2. Case classes are a nice, simple way of creating basic data structures. In Java, creating a data structure that should have a proper equality implementation and a nice toString is a tedious chore. Granted, I think Clojures record's are better since they give you immutability, too.

3. Closures. Other languages also have them, but Java does not. Being able to use closures can really help deal with things such as handling events. In Java, you have to resort to creating inner classes, some of which end up instantiated as members of the class.

4. Judicious use of implicits can give you some half-decent DSLs.

5. 3+4: A nice implicit conversion of a one- or two- line block into an appropriate instance of a ManagerAdapterEventListener can really simplifiy the code.

6. The mixed paradigm approach can be a blessing sometimes. I do prefer the functional approach. However, if you have integrate with a heavily object-oriented framework, being able to be object-oriented can be helpful.

Overall, I would generally prefer Scala over Java for my projects. However, I do prefer Clojure over Scala.

On the other hand, anything that you want to work at a slightly higher level, such as closures or higher-order functions, Java just gets in your way since you have to it all by hand.

Thinking about Scala, there are a couple of problems with its simple/complexity balance:

1. Some things that appear fairly simple actually explode into a huge mess of complexity under the hood. Often, that's not a problem. However, sometimes it becomes a problem because you don't really know what's going on.

2. Some things that should be simple and straightforward, like iterating through an array, are impossible. These are cases were the language is actually removing some of the power of the underlying platform.

In Xmonad, I have configured twenty different workspaces, and I can easily swap them in and out of any given monitor. With a triple-monitor configuration, this is quite handy.

However, if you are only using objects, calling methods, or even implementing interfaces, interoperation for Clojure is quite nice.

In general, the best advice that I have heard and read all points to going with a local bank or credit union. Unless you have millions of dollars, you're just a number to a large bank. With a local institution, you can develop relationships with the people in charge.