The software companies themselves often argue that they don' really want software patents. However, the fact that other can file patents puts them into a position where they need to file patents themselves for protection. It's just a stupid arms race. Now and then, a patent troll with noting to lose shows up and shakes up the picture. You could call it a sort of IP terrorism :-)
IIRC i4i is not a patent troll. It's a company with real products, users and - and that prevents it from being called a patent troll - probably licenses the patents from others.
I am all in for banning obvious or bad patents, as well as shortening their duration, but, perhaps, the i4i patents may be really original or innovative.
Microsoft is known for talking partnership, maybe acquisition, learning all they can and then launching a competitor that kills their "partner". Having strategic patents is the only way a small company can defend from this.
Also, I like the way their name sounds. Sounds appropriate.
I mean, they're not a troll in the way that they're developing their product, but they're a troll in the way that their patent is for a way of editing custom XML. Really?
The versioning nomenclature seems somewhat chaotic... here it says 10.5 and their current version is 10.10 and on the linked page they refer to 10.1 and also talk about 10.50.
I guess that 10.10 == 10.1 and 10.5 == 10.50 but it is a bit confusing...
Oh, and the download crashes with SIGBUS on my MacPro running 10.6 :(
Actually, the 10.10 is because of the Unite component. When they released the official new version, 10, they didn't have Unite ready yet, it was on another branch, the 10.10 (they reserved a few numbers for hotfixes for the version without Unite).
Why on earth would you recommend Agave syrup as a sweetener when it has an even higher fructose/glucose ratio than the dreaded HFCS? There are sweeteners that are 100% glucose including plain old corn syrup but also other nice alternatives (maple syrup etc...) or even refined dextrose...
This was really very interesting. I for one was mostly ignorant to the big difference there was between glucose and fructose. Also the bit on ethanol was quite interesting in itself.
The fact that HFCS is made from normal corn syrup (almost 100% glucose), which is processed into fructose seems almost ironic.
Is it known what the contractor was hired to do? I guess Microsoft didn't just post on rent-a-coder to get the lowest bid on "a microblogging site like Plurk.com".
How deeply was MSFT involved in the project spec and to what degree was that spec based on Plurk?
Keyboards really seem to be polarizing smartphone users these day. I am not very fond of sliding keyboards, but some of my friends would never consider buying a phone without a "full" keyboard...
I've had Nokia E71 for over a year now and I've never had any problems with the keyboard. And it's not a sliding keyboard (it's more blackberry like), so it has a lot smaller keys than this one.
One can train his/her fingers to press those small buttons precisely with some exercise & learning. Remember we all must learn to use any novelty. There are some really fine muscles on fingertips which are adjustable to perform any task.
I think the Droid might be converting a lot of these people. I have heard several Droid users say that the keyboard is bad, and the onscreen keyboard was actually better than the physical keyboard.
I thought that at first, but I've come to be faster with the hardware keyboard than with the onscreen one. If hardware keyboard input still provided predictive autocomplete suggestions, I'd be in heaven; but even without the autocomplete, I'm using the hardware keyboard almost exclusively.
This might have more to do with the Droid keyboard actually being that bad (it is rather cramped compared to the G1) than individual users developing a global preference.
Sure, there are probably better keyboards. I was just saying that "keyboard only" people might buy the Droid and thereby be forced to learn that onscreen keyboards are not that bad after all.
That very much depends on your definition of a String.
I'm not sure what you mean by reversing a string not being equal to reversing its characters. It's certainly not always equal to reversing its bytes (depending on the encoding). Same goes for Strings that are implemented with UTF-16 characters (e.g. Java, win32 wchar_t etc.) all suffer from bad abstractions driven by implementation/efficiency concerns.
His point is that the reverse of the two character unicode string "LATIN-SMALL-LETTER-O COMBINIG-DIAERESIS" is not "COMBINING-DIAERESIS LATIN-SMALL-LETTER-O", but the original "LATIN-SMALL-LETTER-O COMBINIG-DIAERESIS". Blame it on the unicode consortium, but that is the way it is.
I wouldn't necessarily blame it on the unicode consortium but rather on the assumption that a character in a programming language should conform to the notion of a character in UCS-4 or some other unicode encoding.
From a programming language perspective, I think it would be ideal if strings could always be viewed as lists of encoding independent characters, such that reversing this list is equivalent to reversing the string.
If you want to be able to maintain a one-to-one mapping to unicode, you will need to use unique characters for an "ä" and an "a with combining-diaeresis" but ideally that should be hidden from the user of the language.
Thus, in my ideal world, both "LATIN-SMALL-LETTER-O-WITH-DIAERESIS" and "LATIN-SMALL-LETTER-O COMBINING-DIAERESIS" would each be one single element of a list of characters which is a string.
At the level of abstraction I would expect from a String object, the reverse of \r\n should be \n\r. Basically, you example is another encoding issue. I think strings should be free from any encoding concerns. Those should be handled when parsing/serializing.
Even in UCS-4, strings are not reversible by reversing the code points. Are you suggesting that Unicode combining characters are an efficiency concern, rather than a correctness one?
A string is more like a bytecode program that can be executed to evaluate to a piece of human-readable text.
There are far more relevant points, such as the fact that the fudged data series isn't even used anywhere in the rest of the program. The code fragment is indeed pretty useless without the entire program. It seems like ESR has stopped looking at the code once he thought he had found what he was looking for. The adjusted data is never referenced in the rest of the program: http://news.ycombinator.com/item?id=964896
Ideally we would have access to the entire program + data and could re-run it to see whether the graph was produced with or without the adjustments enabled. It is very well possible that the program was altered after the graph was plotted and before that version of the source became public.
So what he wants is a modern language in which to write fast programs for NaCl? I find Go to be a rather strange choice for that given that it is quite new and a bit unoptimized. I think that D might have been a more intuitive choice as it provides you with a mature environment to write native code that does way with a lot of the pain you get when using C++
Than again, if you want to be really cutting edge and be mentioned in a lot of conversations, Go is probably a much more interesting choice as it as more of a hot topic right now.
