Sure, some people will be idiots looking for prescriptions. But think of the number of people who every year show up at doctors' offices and emergency rooms across the country because they have cold/flu symptoms. How many millions of doctor visits can you filter out with T1 support every year?
Imagine if every user incident was immediately sent to a developer. Even if the incident was that the user didn't have their PC plugged in. It wastes the developer's time, it could have been handled much faster by a T1 support person, and it would have left more time for the developer to focus on critical issues that are beyond the scope of T1 support.
Heck, my wife has a vitamin B12 deficiency. She can feel certain symptoms act up when her B12 starts getting low. If she could just go down to clinic and get a B12 test, she could schedule an appointment for a shot. Unfortunately, our insurance will only cover the test if it is recommended by a doctor. So in order to get the shot, we have to deal with a doctors appointment to get the lab referral, then the lab, then an appointment for the shot, then a follow up.
Each of those appointments are billed at $125, and the lab appointment is even more. And we pay a $25 co-pay on every one of them. Over $500 ($100 after insurance) to cover a $0.20 shot. Cutting the referral and follow up appointments to 10 minute virtual visits (which is already longer than we actually see the doc in person) drops that to $390+ and saves us 2 trips across town.
As someone who grew up in a small town called Oregon (pronounced Or-gon), I can fully appreciate people who specify that they are speaking about a State instead of a city. At least in Oregon we can usually pick out people talking about the state as it is usually referred to as "Orgin".
I think your assertion that "Silverlight will die out soon enough" is just as retarded as the other assertions on this topic that suggest that "Java will die out soon enough".
A Closed Container, when you are being arrested, could contain a weapon. A day planner is large enough that it could easily contain a weapon. A cell phone could be used to smuggle a weapon, ammo, or a bomb, BUT, as the majority has rightfully ruled, those threats are not contained in the DATA on the phone. So if a police were to arrest you, and feared that you may have a shiv stashed in your phone, they are completely with in their rights to pop the case on your cell phone and ensure that there are no weapons inside of it. This ruling reiterates that they are NOT with in their rights to turn on your phone, flip through your address book, recent calls, and text message to ensure that there are no weapons in it.
If you have an address book, or day planner, you could use it to hold a gun or a knife. So an arresting officer has the right to open it and ensure that there is nothing that could jeopardize their safety in it. They should not be reading the papers, BUT, if you have a 8x10" glossy photo of you putting a round into someone...
The argument here, as I understand it, is that the majority felt that there is no need to peruse the DATA on the phone to ensure that it will not jeopardize the officer's safety. You can not store a gun or a knife in binary format. So while the cops could crack the case and ensure that there are no hidden contents in side the case, they can not flip through your address book, recent calls, or text messages.
Terrorism is: "the calculated use of unlawful violence or threat of unlawful violence to inculcate fear; intended to coerce or to intimidate governments or societies in the pursuit of goals that are generally political, religious, or ideological."
Attacks on the military can be considered terrorism.
Attacks by crack pots who have no agenda of social change, regardless of the horror, are not terrorism.
For instance: Bombing of the USS Cole = Terrorism. Ft Hood shootings = Premeditated murder by a mentally unhinged man.
Meh I was too lazy to identify specific browsers to specific OSs. I deal with IE6-8 and FF Windows users daily. We have a hand full of Mac users at the corporate office that I don't work with often, but they appear to be running my apps with out problem as well.
I wouldn't say that's quite a fair estimate in this case. Silverlight apps are still cross platform (mine run identically on Win 2k, 2k3, 2k8, XP, Vista, 7, and even a few Mac clients running IE6, 7, 8, and FF3.5) and will continue to be so in v4. But, if you call COM services, they only exist in Windows anyways. So who' cares that the COM functionality only exists in the windows bin, so long as it compiles and throws an exception when COM services aren't available for Mac bins.
This is hardly the dreaded lock-in that people are making it out to be. It's an added tool that (IMO) no one should ever use.
It's like claiming that Mono is a lock in because it contains extra functionality that exploits extra functionality available in Linux environments.
If you want to do cross platform development, you must make sure you either account for all environments, or explicitly only use those entities that are proven safe. It is really quite simple to make an HTML page (with a JSP/PHP/Ruby/what ever) back end that will not render correctly on different platforms. Or toss a couple of OS API calls in Java and watch it bomb out when you run it on a different OS.
Heh, whoops. Slight mistake in my transcription. I double checked, and you are indeed correct, US consumption is 20M barrels/day, not 20B.
I didn't source the 1.5T in reserves, but it doesn't surprise me. It's largely immaterial, the cost per barrel of the 1.5T is higher than the cost per energy unit for alternative options. So while we will eventually tap those reserves, the rate of consumption will likely have dropped significantly as more people are consuming other forms of energy.
1.5T available barrels of oil / 20B barrels consumed daily by the US = 75 days
hmmm... That doesn't seem that great IMO.
Personally, my car runs on veggie oil, so I'm not in an "OMG Were all gonna die!" panic streak, but I'm pretty sure you're screwed.
Realistically though, what we have now is not a true free market, it is impossible to have a consumer base that is well enough informed and a corporate base that is motivated by profit over dividends. Capitalism fails in the same way that Communism does. In a perfect environment, both would flourish. But out side of academia, no such environment exists. The only logical conclusion is that some balance of free market, oversight, subsidies, and regulation will work.
Getting intelligent and open minded individuals to debate out differing points of view on that balance is what give our economy strength. Unfortunately, the media loves a good polarizing story and has managed to turn damn near every political debate into a hot button "our way or NO WAY" fight.
If you leave it to the free(er) market, the cheapest production will always get the most pressure. When sales start dropping again, more lobbying and pressure will come to bear to open up more reserves. And each time they move to the next cheapest production, prices will rise. Eventually opening the door for other more competitive fuel sources.
Virtually all (all that I have ever worked on) gasoline cars use the vacuum created in the intake plenum to operate the brake booster. Some cars use an electric vacuum motor to maintain the power breaks in designs where there is not a consistent vacuum or not accessibility to the plenum.
If you have a leak in your plenum or vacuum booster line, your engine should run rough and your breaks will be much harder too push.
The system will never prevent the application of the breaks, but it does mean instead of having power breaks, you are relying on the mechanical advantage of the pedal and your own leg power to stop the car. If you go back to the 60's you'll see "Power Brakes!" as an option you could add to your car.
Another option to shut down the cruise would be to put the car in neutral. If the engine continues to rev uncontrolled, it likely isn't the cruise control that is at fault.
I have experienced 3 sudden acceleration incidents. 1 was in my Fiero when the 15 year old Cruise Control vacuum got stuck (turning off the CC restore normal driving) and the 2 others, in a '87 Dodge Raider and an '06 Golf TDI we both due to floor mats not being properly installed. The velcro backing on the Dodge's mats had worn out, and the dealer threw in rubber mats on top of the stock mats in the Golf. In both cases the mats had crept forward enough to interfere with the gas pedal.
I'm not saying that there isn't a problem with any specific design, but in my personal experiences the faults have tended to center around pedal interference and/or aging mechanical devices.
Well that's good, I guess those folks to died/suffered from Guillain-Barré syndrome due to the flu vaccine in '76 will be glad to know that it never happened.
Unless of course the company that owns the patent on the glaze is located in California, and this law will result in the earning billions and requiring them to ramp up a few new production facilities. Which would create jobs and tax income for the state.
But the cynic in me is guessing that some patent holding company greased the wheels of government to ensure that their off shore based company can reap some huge IP profits off the whole deal.
1) If you don't approach science as a whole, from the angle of challenging expectations, you're doing it wrong. We don't prove that theories are "right", we fail to disprove them. So if you find the concept of disproving theories to be personally insulting, you have no business in a lab.
2) Given the attitude you've shown in this thread you appear to have the interpersonal skills of a Hymenoepimecis argyraphaga wasp. If you behave so improperly when not behind a computer, I would venture a guess that you are all but un-employable, regardless of how intelligent you feel you are. If you are gainfully employed, I would appreciate it if you could conduct yourself in a professional manor when participating in a public debate.
It's really too bad that a cable company doesn't have any other means of communicating with their customers other than the internet. If only some how they could find out where their customers live, which I admit does sound like a startling infringement on their customers' right to privacy, they could convey such a warning with out worrying about web etiquette or spam filters.
-Rick
PS: In case your browser doesn't support them, there are sarcasm tags on the proceeding paragraph.
That blog is a sad excuse for Journalism. Unfortunately I am also not surprised that/. posted the worst parts of it, nor that most comments attempting to point out the obvious bias of the author are labeled as MS fanatics and modded down.
I have been descriped as a happy pessimist though.
The article states quite clearly that the accenture/.net system could only achieve 2.7ms/transaction. It also states the system they bought achieves.4ms/transaction. So sure the LSE CTO could just be lying to make himself look good for spending $30 million to buy the company that built this platform... But whatever, its not fanaticism, the system they are buying is better (ACCORDING TO LSE) than the Accenture system.
Which was exactly my point!
The new LSE system is better than the Accenture system.
I'm sure we can all agree on that. Software implementation A is better than software implementation B. Using that as the frame work of our argument, how is it not asinine to say that "The OS that Software implementation A runs on is better than the Development Platform that Software implementation B was built with"?
Judging by the number of people who missed my point and the rating of my initial post (redundant, WTF?) I would concede that I have poorly argued my point. That point being that the author of the blog is making absurd statements about the.Net framework based on a single implementation for which it was either technically limited, or implemented poorly.
The author even quotes the original article that states the decision wasn't due to the.Net framework, but with the TradElect software. And then the author goes on to attack the.Net framework as if it were the sole reason for the change.
So no, I am not a rabid MS fan boy. Heck, if I were working on a system with that tight of transaction time, it would be highly unlikely that I would use anything as abstracted as.Net. Going with a Linux based solution where we could cherry pick and tweak the hardware and drivers, and build any necessary functionality into the kernel would likely provide for a significantly faster base.
And with that said, I'm not going to develop end user client apps in low level code for a custom linux kernel. I would switch to a more abstracted language as a solution. Whether that's a Java or.Net app, or even a PHP web site.
So you think it would not be asinine to complain that Java could not perform as well as Windows NT?
My problem isn't with the performance difference between the TradElect software and the Chi-X software. My problem is with the author drawing absurd conclusions that were directly refuted by the article he was quoting.
Good call. I haven't worked in C in almost a decade now and reversed the concepts in my mind.
I would still expect that interactions with an array stored in a block of memory being directly accessed in C++ with out bounds checking would execute faster than interacting with a generic list in.Net.
A generic list, even if it is array based, is going to be on the stack an array of pointers to other points of the stack and the heap.
Hardly. My complaint isn't about the TradElect software's performance. It was slower. But why was it slower? Is the implementation crap? Could it be redesigned to run faster while still running from the.Net framework? Or is it the inherent lag of running inside a sandbox that prevents it from executing as fast as the "GNU/Linux" solution?
My complaint is that the author is roasting the.Net platform as compared to "GNU/Linux". That is like comparing the performance of Java to OS/2. One is a programing platform, the other is an OS.
The author quotes from the article valid complaints about the TradElect system, and then extrapolates that due to the valid concerns LSE has with TradElect, that the.Net platform is inferior in all regards. Although he never explains what programming platform he believe.Net to be inferior to.
That said, if I were working on a system that depended on sub millisecond execution of complex functionality, I probably wouldn't go with.Net either. The fact that you are running inside a VM-like sandbox explicitly means you are going to have worse performance than a natively compiled and executed application.
I never said that they weren't. I said that denigrating one programming platform as a whole based on a single metric with a huge variety of implementations was asinine.
Lets say you and I both develop a trading system. Mine is PHP based, yours is C++ based. My transactions occur in 1ms, yours take 2ms. Should I therefore argue that PHP is faster than C++? No, because it would be idiotic to make such an assertion with out explicit knowledge of both implementations. And even with such knowledge, one could only meaningfully argue that one is faster than the other at that specific task.
That said, if I were working on a system that depended on sub millisecond execution of complex functionality, I probably wouldn't go with.Net either. The fact that you are running inside a VM-like sandbox explicitly means you are going to have worse performance than a natively compiled and executed application.
If you're trying to shave run time on complex functions down to sub millisecond times, I would expect that bounds checking, type safety, and thread safety are low on your concerns. One would hope that they validate all input and ranges before the data gets to the critical calculation portion, but I would not be surprised at all if they dropped all modern safety features in favor of every bit of performance available.
It should also come as absolutely no surprise that a C++ pointer based linked list running native locally on the OS performs faster than a.Net Generics List running as CLR in the.Net run-time environment.
The article is individuals who state that the TradElect software is slower than the Chi-X software. The highly biased author then extrapolates that.Net is slower than "GNU/Linux-based software".
They are also talking about trading a $65 Million piece of software for a $30 Million plan to write a piece of software.
The author is highly biased and inflammatory. MS's.Net framework is NOT the answer in every situation, but it is a solid platform for Windows/Web based development.
I'm all for ragging on crappy software, business practices, taxation, etc... coming out of Redmond, but honestly, pissing on the.Net framework because someone developed an application that was 2.3 milliseconds faster at a custom task is a bit asinine.
Sure, some people will be idiots looking for prescriptions. But think of the number of people who every year show up at doctors' offices and emergency rooms across the country because they have cold/flu symptoms. How many millions of doctor visits can you filter out with T1 support every year?
Imagine if every user incident was immediately sent to a developer. Even if the incident was that the user didn't have their PC plugged in. It wastes the developer's time, it could have been handled much faster by a T1 support person, and it would have left more time for the developer to focus on critical issues that are beyond the scope of T1 support.
Heck, my wife has a vitamin B12 deficiency. She can feel certain symptoms act up when her B12 starts getting low. If she could just go down to clinic and get a B12 test, she could schedule an appointment for a shot. Unfortunately, our insurance will only cover the test if it is recommended by a doctor. So in order to get the shot, we have to deal with a doctors appointment to get the lab referral, then the lab, then an appointment for the shot, then a follow up.
Each of those appointments are billed at $125, and the lab appointment is even more. And we pay a $25 co-pay on every one of them. Over $500 ($100 after insurance) to cover a $0.20 shot. Cutting the referral and follow up appointments to 10 minute virtual visits (which is already longer than we actually see the doc in person) drops that to $390+ and saves us 2 trips across town.
-Rick
A scheduled office visit with a Physician's Assistant at my local clinic costs $125 cash. And he's not even a doctor!
-Rick
As someone who grew up in a small town called Oregon (pronounced Or-gon), I can fully appreciate people who specify that they are speaking about a State instead of a city. At least in Oregon we can usually pick out people talking about the state as it is usually referred to as "Orgin".
-Rick
I think your assertion that "Silverlight will die out soon enough" is just as retarded as the other assertions on this topic that suggest that "Java will die out soon enough".
-Rick
As an aside, Flex has about 268 job opportunities
Funny, on Dice.com, Silverlight has 421 job opportunities.
-Rick
This isn't some gross abuse of the bill of rights. This is for items just like this: http://www.dillonprecision.com/content/p/9/pid/23863/catid/14/Dillon__039_s___039_Plan_B__039__Day_Planner
A Closed Container, when you are being arrested, could contain a weapon. A day planner is large enough that it could easily contain a weapon. A cell phone could be used to smuggle a weapon, ammo, or a bomb, BUT, as the majority has rightfully ruled, those threats are not contained in the DATA on the phone. So if a police were to arrest you, and feared that you may have a shiv stashed in your phone, they are completely with in their rights to pop the case on your cell phone and ensure that there are no weapons inside of it. This ruling reiterates that they are NOT with in their rights to turn on your phone, flip through your address book, recent calls, and text message to ensure that there are no weapons in it.
-Rick
If you have an address book, or day planner, you could use it to hold a gun or a knife. So an arresting officer has the right to open it and ensure that there is nothing that could jeopardize their safety in it. They should not be reading the papers, BUT, if you have a 8x10" glossy photo of you putting a round into someone...
The argument here, as I understand it, is that the majority felt that there is no need to peruse the DATA on the phone to ensure that it will not jeopardize the officer's safety. You can not store a gun or a knife in binary format. So while the cops could crack the case and ensure that there are no hidden contents in side the case, they can not flip through your address book, recent calls, or text messages.
-Rick
Terrorism is: "the calculated use of unlawful violence or threat of unlawful violence to inculcate fear; intended to coerce or to intimidate governments or societies in the pursuit of goals that are generally political, religious, or ideological."
Attacks on the military can be considered terrorism.
Attacks by crack pots who have no agenda of social change, regardless of the horror, are not terrorism.
For instance:
Bombing of the USS Cole = Terrorism.
Ft Hood shootings = Premeditated murder by a mentally unhinged man.
-Rick
Meh I was too lazy to identify specific browsers to specific OSs. I deal with IE6-8 and FF Windows users daily. We have a hand full of Mac users at the corporate office that I don't work with often, but they appear to be running my apps with out problem as well.
-Rick
I wouldn't say that's quite a fair estimate in this case. Silverlight apps are still cross platform (mine run identically on Win 2k, 2k3, 2k8, XP, Vista, 7, and even a few Mac clients running IE6, 7, 8, and FF3.5) and will continue to be so in v4. But, if you call COM services, they only exist in Windows anyways. So who' cares that the COM functionality only exists in the windows bin, so long as it compiles and throws an exception when COM services aren't available for Mac bins.
This is hardly the dreaded lock-in that people are making it out to be. It's an added tool that (IMO) no one should ever use.
It's like claiming that Mono is a lock in because it contains extra functionality that exploits extra functionality available in Linux environments.
If you want to do cross platform development, you must make sure you either account for all environments, or explicitly only use those entities that are proven safe. It is really quite simple to make an HTML page (with a JSP/PHP/Ruby/what ever) back end that will not render correctly on different platforms. Or toss a couple of OS API calls in Java and watch it bomb out when you run it on a different OS.
-Rick
Heh, whoops. Slight mistake in my transcription. I double checked, and you are indeed correct, US consumption is 20M barrels/day, not 20B.
I didn't source the 1.5T in reserves, but it doesn't surprise me. It's largely immaterial, the cost per barrel of the 1.5T is higher than the cost per energy unit for alternative options. So while we will eventually tap those reserves, the rate of consumption will likely have dropped significantly as more people are consuming other forms of energy.
Good catch on my mistake though, thanks.
-Rick
1.5T available barrels of oil / 20B barrels consumed daily by the US = 75 days
hmmm... That doesn't seem that great IMO.
Personally, my car runs on veggie oil, so I'm not in an "OMG Were all gonna die!" panic streak, but I'm pretty sure you're screwed.
Realistically though, what we have now is not a true free market, it is impossible to have a consumer base that is well enough informed and a corporate base that is motivated by profit over dividends. Capitalism fails in the same way that Communism does. In a perfect environment, both would flourish. But out side of academia, no such environment exists. The only logical conclusion is that some balance of free market, oversight, subsidies, and regulation will work.
Getting intelligent and open minded individuals to debate out differing points of view on that balance is what give our economy strength. Unfortunately, the media loves a good polarizing story and has managed to turn damn near every political debate into a hot button "our way or NO WAY" fight.
If you leave it to the free(er) market, the cheapest production will always get the most pressure. When sales start dropping again, more lobbying and pressure will come to bear to open up more reserves. And each time they move to the next cheapest production, prices will rise. Eventually opening the door for other more competitive fuel sources.
-Rick
Virtually all (all that I have ever worked on) gasoline cars use the vacuum created in the intake plenum to operate the brake booster. Some cars use an electric vacuum motor to maintain the power breaks in designs where there is not a consistent vacuum or not accessibility to the plenum.
If you have a leak in your plenum or vacuum booster line, your engine should run rough and your breaks will be much harder too push.
The system will never prevent the application of the breaks, but it does mean instead of having power breaks, you are relying on the mechanical advantage of the pedal and your own leg power to stop the car. If you go back to the 60's you'll see "Power Brakes!" as an option you could add to your car.
Another option to shut down the cruise would be to put the car in neutral. If the engine continues to rev uncontrolled, it likely isn't the cruise control that is at fault.
I have experienced 3 sudden acceleration incidents. 1 was in my Fiero when the 15 year old Cruise Control vacuum got stuck (turning off the CC restore normal driving) and the 2 others, in a '87 Dodge Raider and an '06 Golf TDI we both due to floor mats not being properly installed. The velcro backing on the Dodge's mats had worn out, and the dealer threw in rubber mats on top of the stock mats in the Golf. In both cases the mats had crept forward enough to interfere with the gas pedal.
I'm not saying that there isn't a problem with any specific design, but in my personal experiences the faults have tended to center around pedal interference and/or aging mechanical devices.
-Rick
Well that's good, I guess those folks to died/suffered from Guillain-Barré syndrome due to the flu vaccine in '76 will be glad to know that it never happened.
-Rick
Unless of course the company that owns the patent on the glaze is located in California, and this law will result in the earning billions and requiring them to ramp up a few new production facilities. Which would create jobs and tax income for the state.
But the cynic in me is guessing that some patent holding company greased the wheels of government to ensure that their off shore based company can reap some huge IP profits off the whole deal.
-Rick
1) If you don't approach science as a whole, from the angle of challenging expectations, you're doing it wrong. We don't prove that theories are "right", we fail to disprove them. So if you find the concept of disproving theories to be personally insulting, you have no business in a lab.
2) Given the attitude you've shown in this thread you appear to have the interpersonal skills of a Hymenoepimecis argyraphaga wasp. If you behave so improperly when not behind a computer, I would venture a guess that you are all but un-employable, regardless of how intelligent you feel you are. If you are gainfully employed, I would appreciate it if you could conduct yourself in a professional manor when participating in a public debate.
-Rick
It's really too bad that a cable company doesn't have any other means of communicating with their customers other than the internet. If only some how they could find out where their customers live, which I admit does sound like a startling infringement on their customers' right to privacy, they could convey such a warning with out worrying about web etiquette or spam filters.
-Rick
PS: In case your browser doesn't support them, there are sarcasm tags on the proceeding paragraph.
That blog is a sad excuse for Journalism. Unfortunately I am also not surprised that /. posted the worst parts of it, nor that most comments attempting to point out the obvious bias of the author are labeled as MS fanatics and modded down.
I have been descriped as a happy pessimist though.
-Rick
The article states quite clearly that the accenture/.net system could only achieve 2.7ms/transaction. It also states the system they bought achieves .4ms/transaction. So sure the LSE CTO could just be lying to make himself look good for spending $30 million to buy the company that built this platform... But whatever, its not fanaticism, the system they are buying is better (ACCORDING TO LSE) than the Accenture system.
Which was exactly my point!
The new LSE system is better than the Accenture system.
I'm sure we can all agree on that. Software implementation A is better than software implementation B. Using that as the frame work of our argument, how is it not asinine to say that "The OS that Software implementation A runs on is better than the Development Platform that Software implementation B was built with"?
Judging by the number of people who missed my point and the rating of my initial post (redundant, WTF?) I would concede that I have poorly argued my point. That point being that the author of the blog is making absurd statements about the .Net framework based on a single implementation for which it was either technically limited, or implemented poorly.
The author even quotes the original article that states the decision wasn't due to the .Net framework, but with the TradElect software. And then the author goes on to attack the .Net framework as if it were the sole reason for the change.
So no, I am not a rabid MS fan boy. Heck, if I were working on a system with that tight of transaction time, it would be highly unlikely that I would use anything as abstracted as .Net. Going with a Linux based solution where we could cherry pick and tweak the hardware and drivers, and build any necessary functionality into the kernel would likely provide for a significantly faster base.
And with that said, I'm not going to develop end user client apps in low level code for a custom linux kernel. I would switch to a more abstracted language as a solution. Whether that's a Java or .Net app, or even a PHP web site.
Use the right tool for the job.
-Rick
So you think it would not be asinine to complain that Java could not perform as well as Windows NT?
My problem isn't with the performance difference between the TradElect software and the Chi-X software. My problem is with the author drawing absurd conclusions that were directly refuted by the article he was quoting.
-Rick
Good call. I haven't worked in C in almost a decade now and reversed the concepts in my mind.
I would still expect that interactions with an array stored in a block of memory being directly accessed in C++ with out bounds checking would execute faster than interacting with a generic list in .Net.
A generic list, even if it is array based, is going to be on the stack an array of pointers to other points of the stack and the heap.
Sorry about the confusion, my bust.
-Rick
How disingenuous.
Hardly. My complaint isn't about the TradElect software's performance. It was slower. But why was it slower? Is the implementation crap? Could it be redesigned to run faster while still running from the .Net framework? Or is it the inherent lag of running inside a sandbox that prevents it from executing as fast as the "GNU/Linux" solution?
My complaint is that the author is roasting the .Net platform as compared to "GNU/Linux". That is like comparing the performance of Java to OS/2. One is a programing platform, the other is an OS.
The author quotes from the article valid complaints about the TradElect system, and then extrapolates that due to the valid concerns LSE has with TradElect, that the .Net platform is inferior in all regards. Although he never explains what programming platform he believe .Net to be inferior to.
That said, if I were working on a system that depended on sub millisecond execution of complex functionality, I probably wouldn't go with .Net either. The fact that you are running inside a VM-like sandbox explicitly means you are going to have worse performance than a natively compiled and executed application.
-Rick
Um.... Trading times are very important:
I never said that they weren't. I said that denigrating one programming platform as a whole based on a single metric with a huge variety of implementations was asinine.
Lets say you and I both develop a trading system. Mine is PHP based, yours is C++ based. My transactions occur in 1ms, yours take 2ms. Should I therefore argue that PHP is faster than C++? No, because it would be idiotic to make such an assertion with out explicit knowledge of both implementations. And even with such knowledge, one could only meaningfully argue that one is faster than the other at that specific task.
That said, if I were working on a system that depended on sub millisecond execution of complex functionality, I probably wouldn't go with .Net either. The fact that you are running inside a VM-like sandbox explicitly means you are going to have worse performance than a natively compiled and executed application.
-Rick
If you're trying to shave run time on complex functions down to sub millisecond times, I would expect that bounds checking, type safety, and thread safety are low on your concerns. One would hope that they validate all input and ranges before the data gets to the critical calculation portion, but I would not be surprised at all if they dropped all modern safety features in favor of every bit of performance available.
It should also come as absolutely no surprise that a C++ pointer based linked list running native locally on the OS performs faster than a .Net Generics List running as CLR in the .Net run-time environment.
-Rick
The article is individuals who state that the TradElect software is slower than the Chi-X software. The highly biased author then extrapolates that .Net is slower than "GNU/Linux-based software".
They are also talking about trading a $65 Million piece of software for a $30 Million plan to write a piece of software.
The author is highly biased and inflammatory. MS's .Net framework is NOT the answer in every situation, but it is a solid platform for Windows/Web based development.
I'm all for ragging on crappy software, business practices, taxation, etc... coming out of Redmond, but honestly, pissing on the .Net framework because someone developed an application that was 2.3 milliseconds faster at a custom task is a bit asinine.
-Rick