Slashdot Mirror
C# Memory Leak Torpedoed Princeton's DARPA Chances
nil0lab writes "In a case of 20/20 hindsight, Princeton DARPA Grand Challenge team member Bryan Cattle
reflects on how their code failed to forget obstacles it had passed. It was written in Microsoft's C#, which isn't supposed to let you have memory leaks. 'We kept noticing that the computer would begin to bog down after extended periods of driving. This problem was pernicious because it only showed up after 40 minutes to an hour of driving around and collecting obstacles. The computer performance would just gradually slow down until the car just simply stopped responding, usually with the gas pedal down, and would just drive off into the bush until we pulled the plug. We looked through the code on paper, literally line by line, and just couldn't for the life of us imagine what the problem was.'"
There is your problem. Quit using systems that yield blue screams of death (literally).
I prefer the "u" in honour as it seems to be missing these days.
hundreds of man hours and a few hundred thousand dollars we have finally put our finger on the problem "It was written in Microsoft's C#"...
Looks like they can't directly blame C# for not releasing memory while they are still holding references to the supposedly deletable objects. But I have seen appallingly low understanding of OO principles among the candidates I interview who had grown up in C# environment. My big grouse is that even in C++ Visual Studio and .NET IDEs inhibit a big "picture" understanding of large and complex code. The number of times I had to berate newbies for including afx.h in a "platform independent" base class headers ...
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
It was written in Microsoft's C#
Hehehehehehhehehe. Bwahahahahahhaa!
Seriously! Any military technology written in C# should automatically be disqualified. It's not vendor neutral. The language has not been around long enough to be proven reliable (*surprise*). And MS constantly makes changes to it so it is unlikely to ever be proven reliable. This smacks of idiocy.
All I can say is, "GOOD!" They got what they asked for. Dumb asses. Their task is hard enough without having to figure out if their technology base is working against them. With so many language choices available which squarely fall outside of my first paragraph's criticisms, this is just dumb.
I can't tell you how many man months I've spent tracking down crashes and bugs which ultimately wind up being MS' bugs. Multiply that times the number of developers which have used MS tools and the thousands of wasted man years becomes unbearable. Either you're not doing anything worth being done of you're a shinny, new, ignorant developer which has yet to get burned.
Every serious development project I've been on which is centered on MS technology, has been plagued with MS bugs. In my book, any developer which willingly picks MS as their technology base is very low on the totem pool because it proves they simply don't have the experience to be allowed to pick the technology base.
The only tool suite I've seen which is consistently worse than MS' is Wind Rivers'. Now there is a company which needs to be put out of business. Seems you have to pay large sums of money for them to fix their own compiler bugs which they otherwise refuse to do.
And oh...hehehehehehehehe. Just in case you missed it the first time.
I've always said that if you use Microsucks shitware, you get what you deserve.
a perfect demonstration of how GC does next to nothing to prevent this type of bug
I think you meant to say, a perfect demonstration of how C#/CLR's implementation of GC has inadequate facilities to detect and prevent this type of bug...