Or to put it another way, because I see you've been misunderstood: Let the code describe what the code does. Methods, classes and variables have names, use them.
If you still need to, let the comments describe *why it does that*. If you need to explain at every turn why it does that, either you're doing things in a weird way or you're over-documenting. You'll risk turning a blind eye to unwarranted comments and spend time maintaining and garbage collecting out-of-date comments.
Even when you do comment, skip the essays. Write down what's important. Spending five paragraphs telling a story about a bug in a library and then leaving out the bug ID in their tracker is to optimize the wrong way. Spend up to two sentences summarizing why and what and what it means, but don't fall through the rabbit hole so the reader doesn't have to.
They didn't have ClearType on Mac OS X. ClearType is a trade name for their strategies for subpixel anti-aliasing rendering in Windows XP and later, as available in GDI, WPF and DirectWrite. It's hard to "dump" something you don't have.
They "didn't port it", most likely because porting would have been a rewrite. I'd be surprised if the three implementations on Windows share any code at all beyond a few basic algorithms.
You're right, and all you said goes for both Grand Central Dispatch and Parallel Extensions (which will show up as a large part of the.NET Framework in.NET 4); there's plenty of material on this front including all of the advantages, so anyone asking themselves the same question as weicco did, just look it up and be pleasantly surprised.
I'm a.NET guy too and I've used PFX in production. I think both PFX and GCD are brilliant and are mostly on par when it comes to functionality, but I think GCD may actually be the neater looking API. I'm sure I could have done some of the things I did with GCD's queues in PFX all this time, but I would have never actually thought of it because it'd require separate task managers and task factories and so on. It took me ten minutes to remove almost all locks from a small Cocoa app I had (serialized access to a database) and the idea didn't even occur to me in several similar.NET apps with PFX close at hand.
It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.
On a thread level, yes. GCD works with tasks/jobs on a smaller level. I don't know if it actually manages its operation system-wide, but it could certainly do it more efficiently with more metadata and finer-grained units of work.
GCD is far more encompassing than just spawning threads. It's mainly a library for task-based parallelization (my wording, not theirs) and has some other goodies in it as well.
For starters, unless it's not apparent by now, just spawning a new thread to run every such job is too heavy. Scheduling a new GCD job (and all of them will get run on one of a bunch of thread pool threads) is on the range of tens of CPU instructions; on Mac OS X, where GCD originated, spawning a new thread steals away in the vicinity of one megabyte (I can't seem to find an exact number) just for various bookkeeping. That's a lot of setup; even if there's a lot of fat to cut there, the best solution is probably not to spawn a new thread every time.
The API is also very neatly designed. Tasks can be created and added to groups or queues and run synchronously or asynchronously. Semaphores, queues and event sources (which will trigger the addition of an event handler to a queue automatically) can all be paused and resumed to more easily control the flow. Neat, especially combined with the creation of queues that you set up to just funnel work onto another queue.
Add to that the existence of several global queues with varying priorities (corresponding to a set of worker threads at each priority) and the potential for smarts for a system that can see the entire picture with regards to load within the program and across the system. I don't know the extent to which such smarts exist already, but I think you'll agree that with more metadata available, such a scheduler would be better equipped than one fiddling with coarser-grained threads.
So yeah, this is nothing like "just" spawning threads. (I've never worked directly with pthread; it may very well reuse threads, but it didn't look like it from the man page you referred to.) None of it, as far as I can tell, is Apple inventing something new and breakthrough, but it's still a damn good API with a good consolidated set of computationally cheap features whose level of abstraction solves problems.
I'd say that the worst thing you can do at any point in life is something that doesn't give you personal fulfillment. That may come as a response of having fun and being productive (and in a further sense of course from values like being kind and respected and so on). If you don't get any fulfillment from programming, if you neither like the challenge of the logical and structural problem nor the craft itself, it's essentially a chore. That probably explains why half the people in this thread would drop everything and half would keep at it, and they both think the other half is wrong.
I'm lucky enough to enjoy programming both in private and at work. I love the challenge it presents, the craft itself, the many possible ways to implement something and the layers together with programming that make it software development. It's a brain teaser with enormous practical potential; it's a chore sometimes, especially when you're told to do x, y and z and x, y and z are *boring*, but it's not an inherent property. I'd certainly keep programming if I won a billion dollars, and to me it's about more than pumping synapses. (Then again, I'm not 60 either.)
Having a shared system thread pool that can spread task load evenly across the entire machine and avoid races when each of the thread pools in a few applications start deciding that they can use much of the CPU for themselves sounds useful to me. Even an optimized application-wide thread pool can't be psychic.
They're an alternate implementation of lambda-like technology. Apple's Chris Lattner wrote the first public announcement on blocks and noted: "To head off the obvious question: this syntax and implementation has nothing to do with C++ lambdas. Blocks are designed to work well with C and Objective-C, and unfortunately C++ lambdas really require a language with templates to be very useful. The syntax of blocks and C++ lambdas are completely different, so we expect to eventually support both in the same compiler."
If only due to type inference, I'd prefer the syntax of C++ lambdas, but Blocks aren't half bad at what they do within the frame of the C model.
Actually, libdispatch is *the* implementation of GCD so far. It is open source alright, but your sentence could be read as if libdispatch was a watered-down, open source safe version of it, which isn't the case.
"diverts resources away from java, which actually is designed to be cross platform, is fully open and is far more mature"
You don't specify what you mean by "mature", but Java (the language) isn't necessarily mature. It's been around for longer than.NET, yes. It's also so heavily rooted in backwards compatibility that it has trouble making progress.
Java isn't designed to be cross platform. Java is designed to *be* a platform, and to run *on* many platforms. Java only ever gives you Java; sometimes, it has native-like lipstick on it under the pretense of integration as "look and feel". Sometimes this matters and sometimes it doesn't.
I'll willingly admit that I code.NET in my day job, and that I like C#. (Now is a good time to adjust your stereotype from "java hater" to "paid off by Microsoft" so that you may ignore my criticism for a different reason.;) I'll hold. Done? Great.) I tried Java first (back before.NET) and I've gone back to reinvestigate several times. I've run screaming from it every single time..NET may not be perfect, at least for the kinds of applications I build, but Java has proven worse.
I won't argue with you about "fully open", and I wish as much as anyone that Microsoft would just open everything up for reimplementation - it's going to happen anyway and there's nothing they'll earn from stopping it. They'd have everything to earn from just open sourcing the entire thing, I'd say; it's not like anyone pays for the.NET framework, base class library and language lineup itself. I would ask you, though, which of Windows 7 and Ubuntu Karmic Koala will ship with more C# applications.
Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.
No, IE had stayed such a train wreck for so long that when they tried improving it they had compatibility pushback. Improving is not the problem; improving and maintaining compatibility with a neglected and inefficient engine (completely, by the way, of their own making) is.
Postel's law's not debunked by "Martian Headsets". I like Joel Spolsky, really, but "Martian Headsets" is maybe the worst thing he's ever written. Microsoft put themselves in this mess with Internet Explorer, and the road ahead is *not* to say that we should just hold everything, or to preclude progress because it's so damn hard. Think about what happens on a sub-atomic layer just inside your CPU every damn second; that's damn hard to set up, and we still made it work from the ground up. The correct course of action is to *do something about it*, and that will be painful for everyone, but the reason it's so much more painful for Microsoft than for any other browser vendor is, simply, "Microsoft".
The reason HTML5 defines tokenization and parsing is because it's meant to level the playing field. You're not angry because the rendering will, in the face of real world applications, turn complex, you're angry because it's already complex in the spec. You should be happy, because the reason it's already complex in the spec is because it already works in the real world! You certainly could, but there's not much left to actually amend the rules with, which makes HTML5 a damn good standard -- wasn't one of Joel's points that the reason HTML is so frustrating is because so much is left to the imagination or that it's all but impossible to build interoperable, perfectly implemented rendering?
Furthermore, I'd like to see one editor that neglects to open any text file with broken UTF-8. (I'm sure they exist somewhere, but I haven't ever seen that happen, and I've worked with some real messes.) UTF-8 is a lot easier and the spec is a lot more rigid, but even so you can't just fail in a real application. If you still believe in Postel's law as applied to XHTML, I encourage you to read http://diveintomark.org/archives/2004/01/14/thought_experiment . "Well, the world is just going to have to get more perfect" has repeatedly turned out to not be a workable strategy. (As long as "the world" actually means "the world". Requiring strictness in a closed, scoped system where helpful recovery actually *would* mean disaster is certainly okay.)
Good point, but if it renders significantly different from the other WebKit browsers (and those improvements aren't merged back), it's one more browser to test, which is one of the only actual potential problems with having many browsers.
Even if the rest of that argument (let's not have competition now that the browser I think is good is winning) made sense and all that matters is killing IE, Chrome is an additive force. In a world with only IE and Firefox, if you disliked Firefox, there'd be no alternative. There are people who like Chrome better than Firefox; if your goal is killing IE, that's *more* switchers, even if a bunch also switch back and forth between Firefox and Chrome.
However, outside of that, there's nothing bad with having many browsers around. What is bad is having many contrary *concepts* around. Chrome didn't drag a new rendering engine in, they used WebKit, which is good. Actually, they used a fork of WebKit, which is bad, but WebKit has been able to handle this stuff by merging in the necessary abstractions in the past.
I'm inclined to believe Microsoft when they say that the vast majority of the features requested were already in the product. At that point, you have to do something about the user interface. We can argue over whether the Ribbon was the best way to go, but if you want to take Microsoft to task for *spuriously custom* UIs, there are much better examples than the Ribbon.
I actually agree with them on the Page Setup thing. You're changing how the document looks and it affects the layout - it should belong near the canvas like everything else that has to do with formatting.
The Ribbon is a good fit for document-based, layout-heavy applications with many commands. It's barely a good fit for all Office applications. It should have stayed in Office, or at least never leaked to applications with much smaller footprints. I'd also like for them to upgrade it with a command search that highlights where to go so that you may learn, not one (like the add-in from Office Live) that just brings you matching commands.
The problem with beating the market is that you can't base your system on the market and consistently outperform it; definitely not all the time, but probably not most of the time either. My guess is that you have to mix in something else, but then there are the problems of choosing that "something else", and making sure that its benefits are enough to strengthen the model.
When you say algorithmic trading and "snap judgments", it seems you're referring to the kind of algorithmic trading that lives and dies by how fast it is when it's racing the rest of the algorithmic models in the order book. From what I've been able to tell, strategies that focus on finding a good signal and maximizing the market exposure at favorable times aren't necessarily subject to those typical Bid/Ask-bound restrictions and have entirely different downsides.
Not every algorithmic strategy is about "getting the trades in before anyone else", and as history shows, not every such strategy is algorithmic. No matter how it's done, it's a mug's game, as you point out. Beyond being quicker on the pedals, algorithmic trading on computers can also keep lots more state, and I think the real payoffs come when you keep the right kind of state and use that to base decisions in a way that has proven to be beneficial. (You can't ever prove that history will repeat itself or that a strategy will work tomorrow, but what else are you going to train it on that's representative of the market?)
The Mac OS X "point release" is variable-size. 10.1 was basically a service pack. Every 10.N release after that has been incrementally larger up to 10.5 where we are now. 10.4 and 10.5 were significant upgrades to the OS and at least as big as the step between Windows 95 to Windows 98 and certainly between Mac OS 8 and Mac OS 9. 10.5 is only similar to 10.1 in that it's a point increment larger than the preceding version.
It's a stylistic choice -- one which I think is stupid and not styli*sh*, but which is nevertheless stylist*ic* -- to keep the "10" meaning "X" in Mac OS X. They also put out more traditional point releases; they are named 10.N.M and are free. So yes, Apple does give out point releases; they do so frequently.
"By genuine I mean fight intellectual property nonsense, not nut jobs who believe that it is ok to just take others work. They don't sound genuine, however. "
They are genuine. They've been trying to save our privacy for the past three years, but the only time anyone notices is when TPB gets in the news internationally.
They have a plan to eliminate medicine patents and replace them with (existing) centralized funding; the overall pile of money involved at different stages of the mutually assured destruction-like patent market would go down, and R&D could focus on R&D.
They want to shorten the lifespan of Copyright dramatically - I think the plan is for 5 years. (This comes out of a continuous discussion between different fields, where every field believes 5 or 10 years is a great duration for every field but their own, because they have to continue making money; thus the only way out besides continuing the stalemate is to just set a new figure across the board.) They also want non-commercial "infringement" even within the short period to always be legal as an extension of the library concept, where public culture is made available for every citizen.
They've been against the law allowing the Swedish Military Radio Institute to tap any Internet traffic crossing the border to listen for weakly defined "outer threats". Not only is it impossible from within Sweden to tell what'll cross the border or not and easy for actual terrorists (or what have you) to route around or use encryption, in order for them to be able to tap *some* traffic, they must be able to filter *all* traffic. Which means that every byte of Internet traffic inside Sweden (including this reply) passes through a supercomputer scanning for dangerous packets, violating the privacy of everyone and using military resources against its own citizen.
They're also against the implementation of the IPRED directive. This is so horrible it won't fit in a paragraph, and I advice you to google it for more information, but suffice it to say that in the process of the media industry prosecuting alleged file sharers (and the evidence could easily be fraudulent) they get to take your house in custody, search it, keep all your digital storage for evidence, slap you with (explicitly allowed) out-of-proportion fines, place the burden on you in civil court to prove that you didn't do anything and force you to take out a magazine ad proclaiming your conviction.
The Pirate Party is easily played as a bunch of schmucks that just want things for free. I can't rule out that such people are members, but it's not the strategy of the party itself, which is canny to a number of issues related to privacy and baby/bathwater situations. As far as piracy goes, though, I'm personally a member who, thanks to the large scale abolishment of music DRM as of late, download from TPB only what I can't get from iTunes otherwise, which is sadly still rather a lot. Although if they get to twist the courts into assuming guilt or causality, I'm not sure why I should be so eager to indirectly support this kind of behavior at all.
Slashdot Mirror
Or to put it another way, because I see you've been misunderstood: Let the code describe what the code does. Methods, classes and variables have names, use them.
If you still need to, let the comments describe *why it does that*. If you need to explain at every turn why it does that, either you're doing things in a weird way or you're over-documenting. You'll risk turning a blind eye to unwarranted comments and spend time maintaining and garbage collecting out-of-date comments.
Even when you do comment, skip the essays. Write down what's important. Spending five paragraphs telling a story about a bug in a library and then leaving out the bug ID in their tracker is to optimize the wrong way. Spend up to two sentences summarizing why and what and what it means, but don't fall through the rabbit hole so the reader doesn't have to.
They didn't have ClearType on Mac OS X. ClearType is a trade name for their strategies for subpixel anti-aliasing rendering in Windows XP and later, as available in GDI, WPF and DirectWrite. It's hard to "dump" something you don't have.
They "didn't port it", most likely because porting would have been a rewrite. I'd be surprised if the three implementations on Windows share any code at all beyond a few basic algorithms.
The onmousedown bit calls a JavaScript function to do that.
Yes, you're right, they're exactly the same thing.
You're right, and all you said goes for both Grand Central Dispatch and Parallel Extensions (which will show up as a large part of the .NET Framework in .NET 4); there's plenty of material on this front including all of the advantages, so anyone asking themselves the same question as weicco did, just look it up and be pleasantly surprised.
I'm a .NET guy too and I've used PFX in production. I think both PFX and GCD are brilliant and are mostly on par when it comes to functionality, but I think GCD may actually be the neater looking API. I'm sure I could have done some of the things I did with GCD's queues in PFX all this time, but I would have never actually thought of it because it'd require separate task managers and task factories and so on. It took me ten minutes to remove almost all locks from a small Cocoa app I had (serialized access to a database) and the idea didn't even occur to me in several similar .NET apps with PFX close at hand.
So, in other words, sobbing.
And yeah, I messed the simile up.
It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.
On a thread level, yes. GCD works with tasks/jobs on a smaller level. I don't know if it actually manages its operation system-wide, but it could certainly do it more efficiently with more metadata and finer-grained units of work.
Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his freedom.
GCD is far more encompassing than just spawning threads. It's mainly a library for task-based parallelization (my wording, not theirs) and has some other goodies in it as well.
For starters, unless it's not apparent by now, just spawning a new thread to run every such job is too heavy. Scheduling a new GCD job (and all of them will get run on one of a bunch of thread pool threads) is on the range of tens of CPU instructions; on Mac OS X, where GCD originated, spawning a new thread steals away in the vicinity of one megabyte (I can't seem to find an exact number) just for various bookkeeping. That's a lot of setup; even if there's a lot of fat to cut there, the best solution is probably not to spawn a new thread every time.
The API is also very neatly designed. Tasks can be created and added to groups or queues and run synchronously or asynchronously. Semaphores, queues and event sources (which will trigger the addition of an event handler to a queue automatically) can all be paused and resumed to more easily control the flow. Neat, especially combined with the creation of queues that you set up to just funnel work onto another queue.
Add to that the existence of several global queues with varying priorities (corresponding to a set of worker threads at each priority) and the potential for smarts for a system that can see the entire picture with regards to load within the program and across the system. I don't know the extent to which such smarts exist already, but I think you'll agree that with more metadata available, such a scheduler would be better equipped than one fiddling with coarser-grained threads.
So yeah, this is nothing like "just" spawning threads. (I've never worked directly with pthread; it may very well reuse threads, but it didn't look like it from the man page you referred to.) None of it, as far as I can tell, is Apple inventing something new and breakthrough, but it's still a damn good API with a good consolidated set of computationally cheap features whose level of abstraction solves problems.
So what you're saying is you want Intel to Dump Core?
I'd say that the worst thing you can do at any point in life is something that doesn't give you personal fulfillment. That may come as a response of having fun and being productive (and in a further sense of course from values like being kind and respected and so on). If you don't get any fulfillment from programming, if you neither like the challenge of the logical and structural problem nor the craft itself, it's essentially a chore. That probably explains why half the people in this thread would drop everything and half would keep at it, and they both think the other half is wrong.
I'm lucky enough to enjoy programming both in private and at work. I love the challenge it presents, the craft itself, the many possible ways to implement something and the layers together with programming that make it software development. It's a brain teaser with enormous practical potential; it's a chore sometimes, especially when you're told to do x, y and z and x, y and z are *boring*, but it's not an inherent property. I'd certainly keep programming if I won a billion dollars, and to me it's about more than pumping synapses. (Then again, I'm not 60 either.)
Having a shared system thread pool that can spread task load evenly across the entire machine and avoid races when each of the thread pools in a few applications start deciding that they can use much of the CPU for themselves sounds useful to me. Even an optimized application-wide thread pool can't be psychic.
They're an alternate implementation of lambda-like technology. Apple's Chris Lattner wrote the first public announcement on blocks and noted: "To head off the obvious question: this syntax and implementation has nothing to do with C++ lambdas. Blocks are designed to work well with C and Objective-C, and unfortunately C++ lambdas really require a language with templates to be very useful. The syntax of blocks and C++ lambdas are completely different, so we expect to eventually support both in the same compiler."
If only due to type inference, I'd prefer the syntax of C++ lambdas, but Blocks aren't half bad at what they do within the frame of the C model.
Actually, libdispatch is *the* implementation of GCD so far. It is open source alright, but your sentence could be read as if libdispatch was a watered-down, open source safe version of it, which isn't the case.
"diverts resources away from java, which actually is designed to be cross platform, is fully open and is far more mature"
You don't specify what you mean by "mature", but Java (the language) isn't necessarily mature. It's been around for longer than .NET, yes. It's also so heavily rooted in backwards compatibility that it has trouble making progress.
Java isn't designed to be cross platform. Java is designed to *be* a platform, and to run *on* many platforms. Java only ever gives you Java; sometimes, it has native-like lipstick on it under the pretense of integration as "look and feel". Sometimes this matters and sometimes it doesn't.
I'll willingly admit that I code .NET in my day job, and that I like C#. (Now is a good time to adjust your stereotype from "java hater" to "paid off by Microsoft" so that you may ignore my criticism for a different reason. ;) I'll hold. Done? Great.) I tried Java first (back before .NET) and I've gone back to reinvestigate several times. I've run screaming from it every single time. .NET may not be perfect, at least for the kinds of applications I build, but Java has proven worse.
I won't argue with you about "fully open", and I wish as much as anyone that Microsoft would just open everything up for reimplementation - it's going to happen anyway and there's nothing they'll earn from stopping it. They'd have everything to earn from just open sourcing the entire thing, I'd say; it's not like anyone pays for the .NET framework, base class library and language lineup itself. I would ask you, though, which of Windows 7 and Ubuntu Karmic Koala will ship with more C# applications.
Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.
No, IE had stayed such a train wreck for so long that when they tried improving it they had compatibility pushback. Improving is not the problem; improving and maintaining compatibility with a neglected and inefficient engine (completely, by the way, of their own making) is.
Postel's law's not debunked by "Martian Headsets". I like Joel Spolsky, really, but "Martian Headsets" is maybe the worst thing he's ever written. Microsoft put themselves in this mess with Internet Explorer, and the road ahead is *not* to say that we should just hold everything, or to preclude progress because it's so damn hard. Think about what happens on a sub-atomic layer just inside your CPU every damn second; that's damn hard to set up, and we still made it work from the ground up. The correct course of action is to *do something about it*, and that will be painful for everyone, but the reason it's so much more painful for Microsoft than for any other browser vendor is, simply, "Microsoft".
The reason HTML5 defines tokenization and parsing is because it's meant to level the playing field. You're not angry because the rendering will, in the face of real world applications, turn complex, you're angry because it's already complex in the spec. You should be happy, because the reason it's already complex in the spec is because it already works in the real world! You certainly could, but there's not much left to actually amend the rules with, which makes HTML5 a damn good standard -- wasn't one of Joel's points that the reason HTML is so frustrating is because so much is left to the imagination or that it's all but impossible to build interoperable, perfectly implemented rendering?
Furthermore, I'd like to see one editor that neglects to open any text file with broken UTF-8. (I'm sure they exist somewhere, but I haven't ever seen that happen, and I've worked with some real messes.) UTF-8 is a lot easier and the spec is a lot more rigid, but even so you can't just fail in a real application. If you still believe in Postel's law as applied to XHTML, I encourage you to read http://diveintomark.org/archives/2004/01/14/thought_experiment . "Well, the world is just going to have to get more perfect" has repeatedly turned out to not be a workable strategy. (As long as "the world" actually means "the world". Requiring strictness in a closed, scoped system where helpful recovery actually *would* mean disaster is certainly okay.)
Good point, but if it renders significantly different from the other WebKit browsers (and those improvements aren't merged back), it's one more browser to test, which is one of the only actual potential problems with having many browsers.
Even if the rest of that argument (let's not have competition now that the browser I think is good is winning) made sense and all that matters is killing IE, Chrome is an additive force. In a world with only IE and Firefox, if you disliked Firefox, there'd be no alternative. There are people who like Chrome better than Firefox; if your goal is killing IE, that's *more* switchers, even if a bunch also switch back and forth between Firefox and Chrome.
However, outside of that, there's nothing bad with having many browsers around. What is bad is having many contrary *concepts* around. Chrome didn't drag a new rendering engine in, they used WebKit, which is good. Actually, they used a fork of WebKit, which is bad, but WebKit has been able to handle this stuff by merging in the necessary abstractions in the past.
I'm inclined to believe Microsoft when they say that the vast majority of the features requested were already in the product. At that point, you have to do something about the user interface. We can argue over whether the Ribbon was the best way to go, but if you want to take Microsoft to task for *spuriously custom* UIs, there are much better examples than the Ribbon.
I actually agree with them on the Page Setup thing. You're changing how the document looks and it affects the layout - it should belong near the canvas like everything else that has to do with formatting.
The Ribbon is a good fit for document-based, layout-heavy applications with many commands. It's barely a good fit for all Office applications. It should have stayed in Office, or at least never leaked to applications with much smaller footprints. I'd also like for them to upgrade it with a command search that highlights where to go so that you may learn, not one (like the add-in from Office Live) that just brings you matching commands.
The problem with beating the market is that you can't base your system on the market and consistently outperform it; definitely not all the time, but probably not most of the time either. My guess is that you have to mix in something else, but then there are the problems of choosing that "something else", and making sure that its benefits are enough to strengthen the model.
When you say algorithmic trading and "snap judgments", it seems you're referring to the kind of algorithmic trading that lives and dies by how fast it is when it's racing the rest of the algorithmic models in the order book. From what I've been able to tell, strategies that focus on finding a good signal and maximizing the market exposure at favorable times aren't necessarily subject to those typical Bid/Ask-bound restrictions and have entirely different downsides.
Not every algorithmic strategy is about "getting the trades in before anyone else", and as history shows, not every such strategy is algorithmic. No matter how it's done, it's a mug's game, as you point out. Beyond being quicker on the pedals, algorithmic trading on computers can also keep lots more state, and I think the real payoffs come when you keep the right kind of state and use that to base decisions in a way that has proven to be beneficial. (You can't ever prove that history will repeat itself or that a strategy will work tomorrow, but what else are you going to train it on that's representative of the market?)
Here we go again.
The Mac OS X "point release" is variable-size. 10.1 was basically a service pack. Every 10.N release after that has been incrementally larger up to 10.5 where we are now. 10.4 and 10.5 were significant upgrades to the OS and at least as big as the step between Windows 95 to Windows 98 and certainly between Mac OS 8 and Mac OS 9. 10.5 is only similar to 10.1 in that it's a point increment larger than the preceding version.
It's a stylistic choice -- one which I think is stupid and not styli*sh*, but which is nevertheless stylist*ic* -- to keep the "10" meaning "X" in Mac OS X. They also put out more traditional point releases; they are named 10.N.M and are free. So yes, Apple does give out point releases; they do so frequently.
"By genuine I mean fight intellectual property nonsense, not nut jobs who believe that it is ok to just take others work. They don't sound genuine, however. "
They are genuine. They've been trying to save our privacy for the past three years, but the only time anyone notices is when TPB gets in the news internationally.
They have a plan to eliminate medicine patents and replace them with (existing) centralized funding; the overall pile of money involved at different stages of the mutually assured destruction-like patent market would go down, and R&D could focus on R&D.
They want to shorten the lifespan of Copyright dramatically - I think the plan is for 5 years. (This comes out of a continuous discussion between different fields, where every field believes 5 or 10 years is a great duration for every field but their own, because they have to continue making money; thus the only way out besides continuing the stalemate is to just set a new figure across the board.) They also want non-commercial "infringement" even within the short period to always be legal as an extension of the library concept, where public culture is made available for every citizen.
They've been against the law allowing the Swedish Military Radio Institute to tap any Internet traffic crossing the border to listen for weakly defined "outer threats". Not only is it impossible from within Sweden to tell what'll cross the border or not and easy for actual terrorists (or what have you) to route around or use encryption, in order for them to be able to tap *some* traffic, they must be able to filter *all* traffic. Which means that every byte of Internet traffic inside Sweden (including this reply) passes through a supercomputer scanning for dangerous packets, violating the privacy of everyone and using military resources against its own citizen.
They're also against the implementation of the IPRED directive. This is so horrible it won't fit in a paragraph, and I advice you to google it for more information, but suffice it to say that in the process of the media industry prosecuting alleged file sharers (and the evidence could easily be fraudulent) they get to take your house in custody, search it, keep all your digital storage for evidence, slap you with (explicitly allowed) out-of-proportion fines, place the burden on you in civil court to prove that you didn't do anything and force you to take out a magazine ad proclaiming your conviction.
The Pirate Party is easily played as a bunch of schmucks that just want things for free. I can't rule out that such people are members, but it's not the strategy of the party itself, which is canny to a number of issues related to privacy and baby/bathwater situations. As far as piracy goes, though, I'm personally a member who, thanks to the large scale abolishment of music DRM as of late, download from TPB only what I can't get from iTunes otherwise, which is sadly still rather a lot. Although if they get to twist the courts into assuming guilt or causality, I'm not sure why I should be so eager to indirectly support this kind of behavior at all.